Re: [E-devel] Systray - Ideas for a new spec
Well, Ive put the old spec you made raster on the wiki (dug up from mailing list archives from 2006!) so everyone can see and discuss it further. Sure would be nice if you could look over it and change anything. Id like to attach it to the SoC idea about the systray, so that if it does get in, then we can produce a working example for the xdg folks to look at. Itll also need some applications that actually use it, so if anyone wants to include some systray code in anything, that too would be cool. Toma On 10/03/2008, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > On Mon, 10 Mar 2008 13:33:21 +0900 Toma <[EMAIL PROTECTED]> babbled: > > > > Heres whats happened so far! > > http://lists.freedesktop.org/archives/xdg/2008-March/009303.html > > > > Here are some of the summaries from people... > > "yeah, i'd really like to see this happen too. it requires someone to write > > the spec and start with implementations ... we've sort of all been staring > at > > each other for a few years now waiting for someone to have the time and > > energy to do it. " > > -A Seigo (KDE Developer) > > > > "It doesn't make sense to try to write a new > > spec without having at least a proof-of-concept implementation. I hate the > > current systray too, and I have somewhere an unfinished attempt at a better > > implementation, but it's in the queue with many other things. Saying how > the > > systray needs fixing is unfortunately not going to do that, somebody needs > to > > find the time to make it happen." > > -L Lunak (KDE developer) > > > > No news from anyone in the Gnome camp yet, but I get the impression > > that everyone, including some people in the E camp that hate the > > notion of having a systray at all. > > Feel free to read the archive so far and/or join in the systray > > bashing on the mailing list there. > > Toma > > > it was the gnome camp last time that poo-pooed any changes to systray. seigo > was all for improving/fixing the spec. i sent changes to the spec to the > list a > full description of the ideas, but nothing happened. i always intended to > actually implement these changes. > > > > On 05/03/2008, Toma <[EMAIL PROTECTED]> wrote: > > > Great. > > > Heres the spec in question if anyone wants to read and add anything. > > > > http://standards.freedesktop.org/systemtray-spec/systemtray-spec-0.2.html > > > > > > Also this interesting little article. > > > http://www.xvsxp.com/interface/menuextrastray.php > > > > > > > > > Toma > > > > > > > > > > > > On 05/03/2008, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > > > > On Tue, 4 Mar 2008 23:59:44 +0900 Toma <[EMAIL PROTECTED]> babbled: > > > > > > > > > > > > > Im trying to get some chatter about a new systray spec on the > > > > > freedesktop.org mailing list. > > > > > Since Im no programmer myself, I would like to try to just solidify > > > > > some points that you all have and then put them all together and > mail > > > > > it into them. > > > > > I figure the problem wont fix itself and some of you have some good > > > > > ideas for it. > > > > > Lets make some noise about this while KDE4 is fresh and see if any > > > > > collaboration in that respect can happen. > > > > > Toma > > > > > > > > > > > > well i've made them before on the wm spec list, so here goes: > > > > > > > > 1. systray "icon" windows are all implemented as solid windows. they > > > > are a hack around using icon windows in good old ICCCM but no better > > > > functionally - just much more obfuscated with all the selection > > > > mechanism stuff. as such they suffer the problems of icon windows: > > > > 1.1 can only have 1 copy of them on screen in 1 place. doesn't allow > a > > > > tray to duplicate visual copies of them or functional ones. > > > > 1.2 they are windows - the implementations all assume that a tray > will > > > > be in the same toolkit as the app (gtk just creates little grey box > > > > windows, kde/qt assume copyfromparent is a good idea for the > background > > > > - which is a bad assumption). as such the spec discourages good > > > > implementation. 1.3 the spec should use the NETWM_ICON property to > > > > deliver an ARGB image to display. the tray can scale, draw, composite > or > > > > whatever it wants. it can no create multiple copies. if the icon needs > > > > to change - a property change will do the job. doing more is probably > > > > abusing systray icons far beyond what they should be used for. > > > > 1.4 as such systray icons have just become a way for apps to avoid > > > > showing a main window but stay running. they function often simply as > a > > > > replacement for iconification in icccm. thus using the same mechanism > is > > > > the better way to go. > > > > > > > > 2. as such icons want some form of interaction with users - do be > able > > > > to click on them to act
Re: [E-devel] Systray - Ideas for a new spec
Hi, I took time to talk to this subject because I wanted to write my proof of concept before replying. In my opinion, a systray is a bad idea. For the last two weeks I kept asking myself, "Why do people want a systray ? What exactly is a systray ? How can I provide it ?". For the first question I've directly asked to anybody I know was using trayer, or wanted a tray on E. The answers were about having a way to be notified, a quick way to show/hide some windows. A few were about using direct actions and each time with the same example, an audio player. And the last one that nobody say directly but somehow is always there, because they are simply used to it. For the second question, the easiest way to find out what exactly is a systray, it's to look at the source. A systray on windows is the only way to move an app outside the taskbar, the only way to keep visible an application running in the background but needs a GUI sometimes and was the only way to provide a pseudo gadget. Nowadays a huge amout of applications running on windows put something in the tray. Most of the time the systray have more applications than the taskbar, and 3/4 of them being hidden to take less place within the bar (so much for the monitoring). So what exactly is a systray ? I dunno, if it's a way to continuously notify why hide the icons and show a bubble ? If it's a way to lighten the taskbar why only the application as the power to choose ? And if it's a way to provide quick actions why do we still need this under our WMs were any one of them can use modules for years ? Well, here is the problem. A systray is a mess in it's basic design. Some half done thing wishing to compete with OS X dock. So write a spec, even good, about something doing a bit of (continuous ?) notification, a bit of quick action and a bit of docking isn't, in my opinion, the greatest thing to do. Of course it will works, but why redo half of the job instead of finishing it once and for all ? First let's have a _real_ fdo specification about notifications, galago's one was refused. It still miss some details, but I think it's a good base. And I believe it's something far more useful than just a common way to blink an icon somewhere in the screen (the urgent flag can already be used to do it). By pushing it a little I did the notification boxes : http://lok.eadrax.org/images/notification_box-3.png http://lok.eadrax.org/images/notification_box-4.png Which means than a good notification spec could cover all the aspect of notifications, popups and icons. Moreover I didn't implemented it but this spec handle actions, their purpose is to reply to an event. A docking specification doesn't seems necessary, we already have everything we need to dock an application like it would be in a tray. IIirk is the proof and IBox is also a solution. And finally for quick actions there is no common way possible. Depending on the purpose of the applications you will not wish to display it the same way. For an audio player, having a module giving you the possibility to play/pause/next/prev with a single click is better than openning a menu and choosing the good action in it. See http://www.kuliniewicz.org/music-applet/ for example. Whereas to quickly change a network like with network-manager you would rather have a popup with a list showing directly the name of the network, if it's protected and how good you catch it. All that using the same look than your WM. Redoing a module for each WM takes more work but end up nicer than reducing everything to a menu. Mixing iiirk and notification together would provide over 90% of what a tray does. Add to that IBar/IBox and you get something near OS X dock. Of course any other combination is possible. All this relying only on the .desktop spec, a notification one and the old NetWM's skip flags, breaking nothing and just requiring sometimes to install a notification plugin. So no I don't think we should change the tray spec, we should forget about it. Even if we do change it, even if we also manage to make the applications following the new one. All we will get is a bunch of icons stacked at their own will in a corner with the ability to open a menu. I would rather like to see a clean and complete notification spec accepted by FDO. Samuel 'lok' Mendes - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Nightly build log for E17 on 2008-03-10 07:09:14 -0700
Build log for Enlightenment DR 0.17 on 2008-03-10 07:09:14 -0700 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: ecore_li http://download.enlightenment.org/tests/logs/ecore_li.log engage http://download.enlightenment.org/tests/logs/engage.log enna http://download.enlightenment.org/tests/logs/enna.log epdf http://download.enlightenment.org/tests/logs/epdf.log Packages with no supported build system: entice, esmart_rsvg, exorcist, python-efl, Packages skipped: camE, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, Packages that build OK: alarm, bling, calendar, cpu, deskshow, echo, eclair, ecore, edata, edb, e_dbus, edje_editor, edje, edje_viewer, edvi, eet, eflame, eflpp, efm_nav, efm_path, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, emotion, emphasis, empower, emprint, emu, enesim, engrave, engycad, enhance, enity, enterminus, enthrall, entrance_edit_gui, entrance, entropy, envision, epeg, ephoto, e_phys, epsilon, epx, equate, esmart, estickies, etk_extra, etk, etk-perl, evas, evfs, evolve, ewl, examine, execwatch, exhibit, exml, expedite, express, exquisite, extrackt, feh, flame, forecasts, gevas2, iconbar, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, moon, mpdule, net, news, notification, penguins, pesh, photo, rage, rain, screenshot, scrot, slideshow, snow, taskbar, tclock, uptime, weather, winselector, wlan, Debian GNU/Linux 4.0 \n \l Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux See http://download.enlightenment.org/tests/ for details. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Ecore_Con_Url patch
On Mon, Mar 10, 2008 at 03:43:04AM +1100, Carsten Haitzler wrote: > On Fri, 7 Mar 2008 15:30:07 +0100 "Cedric BAIL" <[EMAIL PROTECTED]> babbled: > > > As I previously discussed, I did have some issue with evas_render not > > being called when my computer receive data too fast. The problem was > > the handling of the download prevented ecore to go into idle and call > > evas_render. > > > > To fix this, this patch change the way the fd handler is used. When > > some curl data are received, I stop all curl fd handler and setup an > > idle handler. This force ecore to go in idle mode and call evas_render > > before reading pending data. > > > > As ecore_file_download suffer the same problem and did want to > > maintain two different user of curl library. I added a new interface > > to ecore_con_url so that if it can directly write some data to any fd > > and used this to reimplement ecore_file_download. This change should > > not have a big impact on file download speed but the interface should > > stay responsive what ever your computer and your download speed is ! > > in cvs :) This patch seems to break linking againts libecore_file.so for me. I am building ecore without curl support and after the latest changes in ecore_file_download.c I get the following linking errors: arm-iwmmx-linux-gnueabi/usr/lib/libecore_file.so: undefined reference to `_ecore_file_download_abort' To me it looks like the _ecore_file_download_abort function just needs to be moved out of the HAVE_CURL ifdef's. Regards Lars Munch - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Problem with "Window Remember (Virtual Desktop)"
Hey there, I have a problem with the remember-window-settings, that is there since this settings exists: If I remember the settings "Virtual Desktop" or "Current Screen" it works fine, but for starting the apps I need to have my focus/view on the screen the app should start on. This is a problem as you might forget that you turned on the remember-settings some time ago and the application simple won't show up when you start it, without an error. Especially if you have really many vdesktops it can be a problem to come to named desktop so you probably might look for an error where is none. So my question is: Is there a way to start this applications in background on the correct screen without viewing it? If not, would it at least be possible to have a little signal that the app will appear when the focus is on screen/vdesktop $x? Furthermore, for the first case, it would be cool to have a little reminder on which desktop the application started, I guess the pager-popup can do that job. As this could really improve the usability (and as I have this problem every month without remembering what the reason was :-) ) I'd be glad to get answers or even better a solution. Cheers, thomasg - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Problem with "Window Remember (Virtual Desktop)"
On 03/10/2008 14:00, thomasg wrote: > Hey there, > > I have a problem with the remember-window-settings, that is there since this > settings exists: > If I remember the settings "Virtual Desktop" or "Current Screen" it works > fine, but for starting the apps I need to have my focus/view on the screen > the app should start on. > This is a problem as you might forget that you turned on the > remember-settings some time ago and the application simple won't show up > when you start it, without an error. I've not tried in the last month... maybe two... but I seem to recall this working for me without errors. If anyone else can confirm this being an issue, I'll steal a monitor from my office and fix'er up. > Especially if you have really many vdesktops it can be a problem to come to > named desktop so you probably might look for an error where is none. > > So my question is: Is there a way to start this applications in background > on the correct screen without viewing it? If not, would it at least be > possible to have a little signal that the app will appear when the focus is > on screen/vdesktop $x? > Furthermore, for the first case, it would be cool to have a little reminder > on which desktop the application started, I guess the pager-popup can do > that job. > > As this could really improve the usability (and as I have this problem every > month without remembering what the reason was :-) ) I'd be glad to get > answers or even better a solution. > > Cheers, > > thomasg > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > -- Regards, Ravenlock signature.asc Description: OpenPGP digital signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Problem with "Window Remember (Virtual Desktop)"
Well, I have to do a self-reply now: Seems the problem is not longer existing - the e17 version on my laptop was too old and it seems that it has been fixed some time ago. On my desktop it works perfectly. Consider the first mail as never written. :) Sorry for the circumstances, thomasg On 3/10/08, thomasg <[EMAIL PROTECTED]> wrote: > > Hey there, > > I have a problem with the remember-window-settings, that is there since > this settings exists: > If I remember the settings "Virtual Desktop" or "Current Screen" it works > fine, but for starting the apps I need to have my focus/view on the screen > the app should start on. > This is a problem as you might forget that you turned on the > remember-settings some time ago and the application simple won't show up > when you start it, without an error. > Especially if you have really many vdesktops it can be a problem to come > to named desktop so you probably might look for an error where is none. > > So my question is: Is there a way to start this applications in background > on the correct screen without viewing it? If not, would it at least be > possible to have a little signal that the app will appear when the focus is > on screen/vdesktop $x? > Furthermore, for the first case, it would be cool to have a little > reminder on which desktop the application started, I guess the pager-popup > can do that job. > > As this could really improve the usability (and as I have this problem > every month without remembering what the reason was :-) ) I'd be glad to > get answers or even better a solution. > > Cheers, > > thomasg > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL and Webkit
Carsten Haitzler (The Rasterman) wrote: > >> Either way, this would allow for engine-specific extensions >> for evas.. wrapping things adequately would allow for things like >> say an "evas3D" lib if really desired. > > sure. 3d INSIDE a "3d object" i can deal with in evas :) > Exactly. Wrap things say a 3d-scene object and do your 3d stuff 'inside' such an object. One can do both immediate-mode and retained- mode kinds of rendering to such a scene object. For the latter type, one could have auxiliary 3d objects which must be 'bound' to such a scene, with coordinates rel to the scene obj,... eg. a 3d-scene object itself might be one such object that one could add to another, and ideally all evas primitives would also be added to such a 3d-scene object. One can extend evas in various ways by suitably having such objects which are like 'canvases' themselves that may support their own kinds of rendering/object system... things like 3d, svg, html, and many others are all possible in this way. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Ecore_Con_Url patch
On Mon, 10 Mar 2008 17:28:55 +0100 [EMAIL PROTECTED] (Lars Munch) babbled: fixed :) > On Mon, Mar 10, 2008 at 03:43:04AM +1100, Carsten Haitzler wrote: > > On Fri, 7 Mar 2008 15:30:07 +0100 "Cedric BAIL" <[EMAIL PROTECTED]> > > babbled: > > > > > As I previously discussed, I did have some issue with evas_render not > > > being called when my computer receive data too fast. The problem was > > > the handling of the download prevented ecore to go into idle and call > > > evas_render. > > > > > > To fix this, this patch change the way the fd handler is used. When > > > some curl data are received, I stop all curl fd handler and setup an > > > idle handler. This force ecore to go in idle mode and call evas_render > > > before reading pending data. > > > > > > As ecore_file_download suffer the same problem and did want to > > > maintain two different user of curl library. I added a new interface > > > to ecore_con_url so that if it can directly write some data to any fd > > > and used this to reimplement ecore_file_download. This change should > > > not have a big impact on file download speed but the interface should > > > stay responsive what ever your computer and your download speed is ! > > > > in cvs :) > > This patch seems to break linking againts libecore_file.so for me. I am > building ecore without curl support and after the latest changes in > ecore_file_download.c I get the following linking errors: > > arm-iwmmx-linux-gnueabi/usr/lib/libecore_file.so: undefined reference to > `_ecore_file_download_abort' > > To me it looks like the _ecore_file_download_abort function just needs > to be moved out of the HAVE_CURL ifdef's. > > Regards > Lars Munch > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Systray - Ideas for a new spec
Samuel (lok) wrote: > Mixing iiirk and notification together would provide over 90% > of what a tray does. Add to that IBar/IBox and you get something > near OS X dock. Of course any other combination is possible. What's an "iiirk"? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Systray - Ideas for a new spec
iiirk is a new module thats in E cvs. Its quite nifty. Toma On 11/03/2008, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > > Samuel (lok) wrote: > > > Mixing iiirk and notification together would provide over 90% > > of what a tray does. Add to that IBar/IBox and you get something > > near OS X dock. Of course any other combination is possible. > > > What's an "iiirk"? > > > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje TEXT problems with ellipses calc
Gustavo Sverzut Barbieri wrote:
> Hi,
>
> Just identified that
>
> part {
> name: "text";
> type: TEXT;
> description {
>state: "default" 0.0;
>rel2 {
> relative: 0.0 1.0;
> offset: 118 -1;
>}
>text {
> font: "Vera Sans:style=Bold";
> size: 20;
> text: "Some text";
>}
> }
>
> will cause Edje to mis calculate and return an empty string as result.
> Increasing or decreasing it by one pixel in width will make it "work"
> again, so it's a bit tricky to found in real world applications (but
> we did).
>
> But trickier than finding this is to get the logic of
> _edje_text_fit_x()... maybe someone else is more familiar with it and
> can provide some insight? If not then I'll dig into it later.
> BTW, why these kind of constructions are not provided by Evas?
> Evas should provide these high level utilities, like how many of some
> given text will fit in given width, height or both (these last 2 in in
> case of textblock). Also, since adding ellipses are a common case, we
> could add it as well. Maybe we could also use this to speed up these
> calcs, since calling all those Evas functions from inside Edje can be
> a bit a hit in performance :-/
I hit a similar problem a while ago, and tried to fix it. The problem
was that when you use shadows etc. the size evas reports for the string
isn't the same size that evas uses for the resulting evas object. This
might be a similar thing.
I agree, more of the logic should be moved to evas as it isn't to easy
to grok what object size a text string will result in.
Sebastian
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
