Gentoo Forums

Since the kde-look thread was drawn out, and no longer revolves so much around the kde-look site but rather the work I'm doing (with the fellas at slicker), I'm making a new topic.

Anyway, here's what I just posted to slicker-devel:

All
I have FANTASTIC NEWS!

I have, as of writing this (in the coffee shop, as usual) written a
functional, working, plugin framework. I've only got one plugin, and it's the
same I've been using (TestCardApplet) but the deal is, it's now being
compiled into a library and being loaded on the fly via exported factory
functions via KLibloader and friends.

I've added several plugin related classes
PluginRoster - scans for available plugins by looking in
 %KDEDIR/share/apps/<appname>/plugins and looks for .desktop files
PluginRoster::Info - a class which represents relevant info on a plugin

PluginListBox & PluginListBoxEntry -- a listbox like class which allows you to
select from an available plugin. Used below, in NewCardDialog.

NewCardDialog -- a dialog box which allows you to create a new card from the
plugin listing. Derived from KDialogBase.

I've also changed the directory structure and makefiles accordingly.

Now, we have

carddesk/
        - main.cpp
        - TestGui.h & TestGui.cpp (for testing)

carddesk/carddeskcore/
        - contains all core carddesk files/classes

carddesk/applets/<appletname>/*
        - contains source etc. for applets. Applets inserted here will be built with
          carddesk and installed appropriately.

Take SPECIAL note of the files in carddesk/applets/testapplet
        it includes:
        -plugin.cpp: the factory functions
        - TestCardApplet.h TestCardApplet.cpp: the plugin itself
        - testcardapplet.desktop: IMPORTANT, describes the plugin

IMPORTANT:
The main TestGui window no longer is allowed to be shut. To quit CardDesk,
right click on a card and select exit. The TestGui window is nothing but a
debug gui, it's not meant for real usage. The main reasoning, here, is that
clicking "Exit" from the cards' context menu is that this signals for Manager
to save settings. TestGui won't be in final builds, anyway.

Also, and this is very important that it is understood, two things:
One: Since the majority of carddesk code is now being compiled into
libcarddeskcore.so, starting carddesk from the build directory is now
somewhat slow. The reason is that since libcarddesk.so isn't being installed
for normal building/testing (unless you want it to) ld won't find it.

So KDevelop, being a great program,
makes instead of the ususal carddesk binary, makes a wrapper script which
invokes LD_PRELOAD stuff so the bin can find the uninstalled libcarddesk.so
library. This only applies to running carddesk uninstalled. If you were to
run make install, the wrapper script won't be used, since libcarddesk.so will
be installed to %KDEDIR/lib.

Two: to run carddesk now, you *will* have to run "make install" in the
carddesk/applets direcotry. This is because carddesk looks for applets in
%KDEDIR/share/<appname>/plugins and expects the library for the plugin to
reside in %KDEDIR/lib. You could, of course, just run make install in
carddesk/ but since this is development, I'd rather just install applets and
run carddesk locally. You can do as you wish ;)


screenshot:
http://home.earthlink.net/~zakariya/fil ... nshot9.png

tarball:
http://home.earthlink.net/~zakariya/fil ... 0.1.tar.gz

Enjoy.
My immediate plans, so you know, are to improve on the PluginListBox class to
look/feel better and show more info from the PluginRoster::Info class.

Also, regarding a couple bugs:
The Xinerama bugs -- I don't even know where to start to fix that. I know
*nothing* of xinerama. I have only a laptop, and its crappy card won't
support xinerama. I can't afford and don't even want a desktop... soo... I'm
up for sugestions. If somebody can point out to me how to check at runtime
for xinerama, I'll be happy to add superficial xinerama support to the Card &
Deck classes. The reason why you're seeing the tail end of the card on the
other monitor is that for right and bottom screen edges, I'm using a hack in
which the card isn't resized, just "shifted"; as right and bottom edges
require a translation and resize for expansion/collapse and this is slower
than for the top and left edges for which only a resize is necessary. I could, at runtime, drop the hack and use proper positioning if xinerama is detected.

The crash on contents resize to zero if a QGridLayout is used... I'll have to look into sources. I might go for
a resizing to 1 pixel and then hiding approach.

And finally, as of right now, I haven't implemented the Tray class and I
haven't implemented saving of manually resized card sizes yet.

Sayonara

All
I just received an awesome third party card, it's not fully fleshed out yet but the crazy SOB who wrote it deserves a beer ;)

Screenshot:
http://home.earthlink.net/~zakariya/fil ... shot10.png
http://home.earthlink.net/~zakariya/fil ... shot11.png

OK, that's all. I'm glad people are writing cards. The api's simple, flexible, and easy to use.

Also, note that the tarball has been updated to include the ClockCard and fixes several bugs. I'm still contemplating how I'll include xinerama support, however. That's going to be a hard one, as I have just a laptop and no money :P

This is awesome. Love that beautiful bean footage. Keep one sending in screenies. btw if you need a larger hard drive I can send an old 20 gig wdc to yah.

Very nice =)

Hey Tomorrow, I was just wondering why you never change the version of the tarball?
I can understand that you may not want to bump the version yet, but what is wrong with 0.1.1 -> 0.1.2 or something like that? It would make it much easier to archive the different tarballs, maybe for historical reasons

BTW, thanks for all the good work, keep it up.

Hey Tomorrow, I was just wondering why you never change the version of the tarball?
I can understand that you may not want to bump the version yet, but what is wrong with 0.1.1 or even 0.1.0.2 or something like that? It would make it much easier to archive the different tarballs, maybe for historical reasons

BTW, thanks for all the good work, keep it up.

IamtheOne wrote:Hey Tomorrow, I was just wondering why you never change the version of the tarball?
I can understand that you may not want to bump the version yet, but what is wrong with 0.1.1 or even 0.1.0.2 or something like that? It would make it much easier to archive the different tarballs, maybe for historical reasons ;)

BTW, thanks for all the good work, keep it up.

The reason why is that I have only 10 megs on my account, firstly, and secondly, because I don't want to start version bumping until carddesk is basically feature complete. The, I'll version bump as I solve bugs and polish the system.

So, someday when you see a carddesk-0.2.tar.gz you'll know carddesk is feature complete, just not ready for mass consumption.

TomorrowPlusX wrote:

IamtheOne wrote:Hey Tomorrow, I was just wondering why you never change the version of the tarball?
I can understand that you may not want to bump the version yet, but what is wrong with 0.1.1 or even 0.1.0.2 or something like that? It would make it much easier to archive the different tarballs, maybe for historical reasons

BTW, thanks for all the good work, keep it up.

The reason why is that I have only 10 megs on my account, firstly, and secondly, because I don't want to start version bumping until carddesk is basically feature complete. The, I'll version bump as I solve bugs and polish the system.

So, someday when you see a carddesk-0.2.tar.gz you'll know carddesk is feature complete, just not ready for mass consumption.

Why don't you get it hosted at sourceforge.net? This is a great project you are working on and I will be following it ever so closely ~ I'm compiling KDE just so I can test it out. Good luck to ya!

I just received an awesome third party card, it's not fully fleshed out yet but the crazy SOB who wrote it deserves a beer

Wow ! Really good !!

The api's simple, flexible, and easy to use.

Well, i wasn't able to compile your latest carddesk Release, because of my old QT Version. But i looked through your code, and i must say that i find it really well designed ( and commented ). Thank you !

Tomorrow, looking for some free webspace?

I got a bit and could host your files for you, if you want contact me via ICQ/MSN/AIM or email.

Regards,

Dylan.

mantis wrote:Tomorrow, looking for some free webspace?

I got a bit and could host your files for you, if you want contact me via ICQ/MSN/AIM or email.

Regards,

Dylan.

Thanks, but I've just been offerred an ftp account which I'll be taking. I do appreciate the offer, though, as my 10mb earthlink account is drying up.

Heh no problems. If you ever need it though just message me. By the way, not going to submit it to sourceforge or going to do it later?

I was looking at the slicker website http://slicker.sourceforge.net/info.htm and it all looks really good. I was just wondering whether anyone has stepped up to work on the other parts of the desktop they have planned.

There's progress, although nothing really visible yet. Not everybody is as fast to create visible results as Shamyl.. :) Anyway, something is already been done as you can see from Shamyl's latest screenshot. A clock! ;)

--
Kurre

rekulaattori wrote:There's progress, although nothing really visible yet. Not everybody is as fast to create visible results as Shamyl.. Anyway, something is already been done as you can see from Shamyl's latest screenshot. A clock!

--
Kurre

Hey -- aren't you the guy who wrote the clock? Sorry about the "crazy SOB" comment. I was just really excited that somebody had written something non-trivial as an applet. It was meant in good fun

TomorrowPlusX wrote:Hey -- aren't you the guy who wrote the clock? Sorry about the "crazy SOB" comment. I was just really excited that somebody had written something non-trivial as an applet. It was meant in good fun

No problem. I actually did find it quite funny. Well, except for the part where you said I deserve a beer .. ;)

I'm trying to get the clock finished so that I could get started with KMenu.

--
Kurre

rekulaattori wrote:

TomorrowPlusX wrote:Hey -- aren't you the guy who wrote the clock? Sorry about the "crazy SOB" comment. I was just really excited that somebody had written something non-trivial as an applet. It was meant in good fun

No problem. I actually did find it quite funny. Well, except for the part where you said I deserve a beer .. ;)

I'm trying to get the clock finished so that I could get started with KMenu.

--
Kurre

Then make it a pizza, or tandouri, or falafel, or whatever. Hmm.. it's 5:30 and I'm about to leave work (and a 2 mile walk home) I think I'll get some indian food ;)

Anyway, I want to warn you, that one thing is likely to change in the carddesk plugin api soon; CardApplet will be getting a cardOrientationChanged() slot, which will be called when the card's orientation changes (duh). The idea is you can resize your Contents accordingly if your widget is not square.

Just so you know. I'll be implementing this and a few more things tonight to make the framework as slicker friendly as possible.

TomorrowPlusX wrote:Anyway, I want to warn you, that one thing is likely to change in the carddesk plugin api soon; CardApplet will be getting a cardOrientationChanged() slot, which will be called when the card's orientation changes (duh). The idea is you can resize your Contents accordingly if your widget is not square.

Funny. I was going to ask if you would do this exact thing, I just forgot about it. The need is clearly visible with the clock.. :)

--
Kurre

I'm planning a little CardApplet. I want it to have buttons in its Tab Area, but there seems to be no possibility to add QButtons to the Tab.
The only way i found is this:

CardApplet has a member Card * _card

Card inherits CardBase

CardBase has a member Tab * _ tab

And finally Tab has a protected virtual member function
mousePressEvents(....)

So, do i have to:

• 1.)
  Draw a Pixmap, which shows some Buttons.
  
  2.)
  Create my own Custom Card and reimplement all mouse Related Functions.
  
  3.)
  Check myself, if and where the user Clicked the Pixmap in order to determine which "Button" was clicked.

Is this the only way to implement Buttons in the Tab Area ? Would this even work ? Or is there another ( easier ) Solution ? I'm glad for any hints.

P.S:
As you can read in one of my previous posts, i am not able to compile carddesk, because of my old Qt Version. And i won't update until gentoo 1.4 -final is out . So my thoughts above are just theoreticall.

quarus wrote:Is this the only way to implement Buttons in the Tab Area ? Would this even work ? Or is there another ( easier ) Solution ? I'm glad for any hints.

I think the Tray class is meant for this. So you'd have to subclass Tray to have the buttons you need.

--
Kurre

quarus wrote:I'm planning a little CardApplet. I want it to have buttons in its Tab Area, but there seems to be no possibility to add QButtons to the Tab.
The only way i found is this:

CardApplet has a member Card * _card

Card inherits CardBase

CardBase has a member Tab * _ tab

And finally Tab has a protected virtual member function
mousePressEvents(....)

So, do i have to:

• 1.)
  Draw a Pixmap, which shows some Buttons.
  
  2.)
  Create my own Custom Card and reimplement all mouse Related Functions.
  
  3.)
  Check myself, if and where the user Clicked the Pixmap in order to determine which "Button" was clicked.

Is this the only way to implement Buttons in the Tab Area ? Would this even work ? Or is there another ( easier ) Solution ? I'm glad for any hints.

P.S:
As you can read in one of my previous posts, i am not able to compile carddesk, because of my old Qt Version. And i won't update until gentoo 1.4 -final is out . So my thoughts above are just theoreticall.

This is what the tray class is for! You read the headers, but not closely enough.

Anyway, I'm working on it; the last tarball I released has a more or less broken tray implementation. When I'm not fixing other bugs, and other junk, I'm working to make it simple enough that you'll just inherit your buttons from either TrayWidget or TrayButton and it'll be more or less automatic.

I just have to say, again, read the source and read the comments in the headers. They tell ALL.

Thanks for your help rekulaattori and TomorrowPlusX !
I must admit that i simply forgot / overread the tray class.

I'm working to make it simple enough that you'll just inherit your buttons from either TrayWidget or TrayButton and it'll be more or less automatic.

Sounds very good. I'm looking forward to it !

I have conducted an interview with TomorrowPlusX for TinyMinds.org, figured some of you might find it of interest - read

This is OT of the thread, but this is a great interview.

One of the "problems" I hear about with Linux is its lack of cohesive GUI. People coming from MS or Mac complain that everything just looks too different. I'm glad to see someone with expertise in graphic design programming for Linux (Art degree & massive programming skills.. I'm turning very green )

Thanks for posting this.

I saw there was some stuff going on for slicker, and I was wondering if there are any updates for us?