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