![[Q]](engine/grafts/newdefault/images/qq.png "Click to quote this passage; Click again to jump to bottom")
aantn said:
Every "Universal Applet" would have to define a few standard functions and would have to able to run with or without an icon.
gilir said:
Universal standart or a GTKSomething commun :) But I think compatibility with applets of gnome-panel will be more difficult than with screenlets.
| #19073 by asomething (0.9744) posted on 8:31am Thursday, January 17th, 2008 |
ketilwaa said:
RYX (the author of screenlets) is busy with a new job. Whise has started branching (or something close to that) here: http://gnome-look.org/content/show.php/Screenlets+New+Bzr?content=73346&PHPSESSID=11d662503b77f30a032b2a1d2f8c5f35
asomething said:
I don't think it's been branched really, but he's definitely been improving on the code. Hopefully RYX will merge all his changes in. Either way, if you use screenlets and aren't afraid of testing changing code, I'd recommend the screenlets-new branch. Here's the launchpad page:
whise said:
the idea of a Universal Applet framework is great , if someone begins to implement i will try to keep up in the screenlets part , screenlets already have some interoperability in the current code , you can find it in the test screenlet
whise said:
the idea of a Universal Applet framework is great , if someone begins to implement i will try to keep up in the screenlets part , screenlets already have some interoperability in the current code , you can find it in the test screenlet
aantn said:
I've been working on the details. I've written up the "why" here and I'll began working on the "how" soon.
aantn said:
I'm not familiar with Kiba's plugin system, so I'm not quite sure what you mean... Do you mind bringing an example of a possible Awn plugin?
) but if it had a plugin based system where even the core stuuf (like the look) were plugins, for (eg) the curves effect the user wouldn't have to recompile a diferent branch/patched awn, instead the user would only have to compile the plugin
some-guy said:
IMO, a dual plugin/applet based system would be the best for awn
malept said:
I'm certainly not opposed to having awn-effects be modularized :)
aantn said:
*Deprecate screenlet.window and replace it with something like screenlet.content. If we want to be able to use screenlets/applets anywhere then they shouldn't be contained in their own window.
aantn said:
I'm willing to work on implementing some of the above myself. What would be the best way to do that? Patches? A new bzr branch?
moonbeam said:
In the context of awn I don't think there is any choice - it's fundamental to the implementation that is used that they're in a window. But I'm assuming you mean to removal awareness of the window's existence from the universal applet code :-) ?
moonbeam said:
Do you anticipate needing to make any fundamental changes in awn-core? I might be missing something but I'm thinking this can be implemented purely as a python module and this could be placed in libawn or libawn-extras?
plunn said:
Just a little check, maybe stupid... ?
aantn said:
Before I start coding, I'm going to wait for an approval from Whise (and RYX?) and make sure that they approve of the entire thing.
aantn said:
Whise: If you could give this a quick glance and tell me what you think of the way I'm implementing it that would be great.
aantn said:
Alright... I just pushed the first real revision.
gilir said:
Fail to start when it want to import caintainer (missing module). Do you forget to add a file into the bzr tree ? (a container.py for example ?) :)
stein said:
I'm writing an application called cream|desktop.
It's planned to be a "slim-line"-desktop displaying files and other information on an animated wallpaper.
stein said:
Would that be OK?
stein said:
I think the best method for showing plugins in different windows could be to use a system called "plugs and sockets".
I read about it time ago, but now I remembered (I was taking a bath - that good for thinking about different things ;-)).
stein said:
The only question is how to draw animations when moving applet from e. g. awn to screenlets.
I think that's impossible with this technique...
ketilwaa said:
Just throwing something out there:
I'm thinking that it would be great to see two things happen (in no particular order):
1. Making Screenlets into an engine that can run both html/iframe
widgets, python based screenlets and maybe some other things
2. Further the development of the project of making a common system
for screenlets/applets.
ketilwaa said:
Aantn: How's your branch coming? Is it possible to install it in addition to Screenlets, without messing stuff up?
If you are thinking of changing its name to Universal applet framework, maybe that could be done as a trial now, so people (e.g. me) can try it out and give feedback.
aantn said:
Screenlets can already show html content using mozembed. I'm thinking of creating an Applet Widget and Vista Gadget wrapper when I have some spare time. Whise already created a Super Karamba wrapper.
plunn said:
I cannot see any reason burning a lot of energy and resources on old software technology when everyone seems to move against Webkit. Webkit comes from Trolltech and also Qt which is the ground for KDE also...
moonbeam said:
Personally, I'm not a big fan of them, but I do recognize the need for them. And that they're occasionally the best choice for certain tasks.
moonbeam said:
webkitgtk is probably a more natural fit for awn.
