Re: [e-users] Development idea
On Thursday 10 November 2005 15:11, Florent Thiery wrote: For example, i'm in a terminal, maximized, then i hit this hotkey and all the windows get rearranged (tiled). Something like the cleanup windows in the actual windows menu, + forcing the current window to unmaximize. Several other window managers (also MS-Windows at one time or another) have options to tile or cascade all windows. I personally find this options annoying and redundant, and apparently I'm not the only one because no modern WM offer these. In fact, something similar to OSX's unzooming, showing all apps (i find this function fantastic, and never found any alternative implementation on linux or windows, but maybe i'm mistaken) You apparently are talking about expose, There are several expose-like programs for Unix - I use kompose which is built for KDE but works more or less for other WMs. The problem these programs solve is the need to quickly locate a required application window w/o sorting through virtual desktop, the taskbar (both of these features are missing from OSX) or manually tabbing through all applications. You also don't want to change the actual dimensions of such applications windows (which will cause the internal content to be rearranged) and once you find the window you are looking for you want to immediately return to the previous display with everything as you left it. So its not a simple problem of rearranging windows' locations and sizes - you want to scale down the windows' content (w/o letting the client application know about it), rearrange everything and then put it back. On virtual desktop capable WMs, the problem can be lessened by out-of-band information (i.e. use desktop 1 for all web browsing, 2 for email, and so on) but it still exists for very crowded desktops. for such WMs these expose-like programs show all windows from all desktops. --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] entrance
On Thursday, 3 March 2005 08:54, Didier Casse wrote:
On Thu, 03 Mar 2005 07:42:09 +0100, Christoph Peltz
[EMAIL PROTECTED] wrote:
H3, H3,
I think I have found it:
Edit the file /etc/sysconfig/desktop and change the following
setting: DISPLAYMANAGER=entrance
It should work, I hope so ^^.
For Fedora core, it's not so straightforward as you need also to
hack:
/etc/X11/prefdm
If anybody finds a really good and straightforward way to install
entrance on Fedora, please let me know.
I have entrance running on Mandrake, and I do not believe it to be
difficult to have the same method working on fedora.
After setting DISPLAYMANAGER in /etc/sysconfig/desktop (I use the value
e17 and hence the next example will use it as well - but replace it
with whatever you want), edit prefdm with the following:
locate the lines that say prefered=gdm, prefered=xdm, etc' and add to
the bottom of the list:
elif [ $DISPLAYMANAGER = E17 -o $DISPLAYMANAGER = e17 ] ; then
preferred=entranced
thats it - you are now good to go: restart X ('service dm restart' on
Mandrake, maybe 'init 3; init 5' elsewhere. don't just zap it with
CTRL-ALT- BACKSPACE) and entrance should come up.
--
Oded
::..
Timing has an awful lot to do with the outcome of a raindance.
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95alloc_id396op=click
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Virtual Desktops
On Sunday, 13 February 2005 05:30, Carsten Haitzler wrote: On Sat, 12 Feb 2005 09:53:21 -0600 Phusion [EMAIL PROTECTED] babbled: I was wondering if other X-Window managers have virtual desktops like enlightenment does? I like the fact that I can move my mouse to the left or right and into another desktop. Some window managers have multiple desktops, but you have to click in the bottom corner to go to that desktop instead of moving the mouse to the left or right. So are there any other window managers that do virtual desktops like enlightenment in that sense? yes. fvwm like 10+ years ago was doing the mouse to edge to flip to a new desktop trick. i can tell you why they dont do it today. it's confusing to new/novice users and amazingly confusing. sure it's great for power users. Most noob oriented window managers have this feature but it is disabled by default. KDE at least has a feature that edge flipping (they call it Active Borders) is enabled only when dragging windows, but this is too disabled by default and only accesible under an Advanced section of the configuration. -- Oded ::.. The military don't start wars. Politicians start wars. -- William Westmoreland --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] xcompmgr on E17
On Sunday, 30 January 2005 16:55, Carsten Haitzler wrote: it wont work with e17. e17 will need its own compmgr. Wouldn't that cause major problems with running e17 applications together with other applications on the same display ? can two compmgrs run simultaneously on the same X server ? no that cant - well ok. yes they can - but thats a technicality. they are like window managers. you only really run 1. this has nothing to do with apps a compmanager is not an app its a very special x client. e17 will eventually one day provide its won compmgr built in - that means u dont (need) to run another one as its pointless. :) i suggest you read up just hos the composite extension, xdamage extension, and a windowmanager work at the lower levels and you'll be much more illuminated and know where i'm coming from. :) I've read a bit about those and I think I understand some of the technical points of the issue, while I have no idea what you mean when you say that E17 uses virtual roots. But I'm more concerned about system integration at this point: will I be able to mix and match applications from differnet environments ? will I be able to run KDE applications on an E17 desktop and have the full capabilities provided by the xcompmgr for the KDE application ? And how about vice versa ? will an E17 application work(*) in a KDE desktop using the standard xcompmgr ? (*) in both cases when I say work, I mean not only render properly and be functional: I mean the full capabilities provided by xcompmgr such as transparencies. -- Oded ::.. Once is happenstance. Twice is coincidence. Three times is enemy action. -- Auric Goldfinger, in Goldfinger / Ian L. Fleming --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Automatic mounting of USB Flash disks and CDROM in E-usbautocam
On Thursday 12 August 2004 04:33, Didier Casse wrote: [...] I believe gnome/mandrake has this already (At least last time I installed a mandrake install for my friend, which was ages ago, this appeared to already happen.) You insert the cd and the CD-ROM icon is automounted on your desktop. I believe that Knoppix does much the same, if I recall correctly. I could be way off :) Brain no workie anymore. For cdrom yes, but not for usb sticks! When I use gnome on my fc2 it automounts my cdrom but not my usb stick. Gnome 2.8 Volume Manager does it properly (it doesn't handle USB properly on 2.6). in Mandrake (not FC), supermount mounts the system and then kded using FAM puts an icon on your desktop for that. But the right way to do that (according to freedesktop.org) is for supermount to emit a signal using the system's DBus daemon, and the desktop's session manager to receive that signal and handle the correct notifications. unfortunatly AFAIK no one integrates properly with DBus yet (though its already in some distros and KDE uses DCop which is almos identical). -- Oded ::.. An algorithm must be seen to be believed. -- D. E. Knuth --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ enlightenment-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] can't get embryo_cc to work
On Wed, 2004-07-28 at 01:23, Michael Jennings wrote: You're arguing that SRPM's are better because they 1 step instead of 3. That's splitting the hair mighty thin. Anyone who knows how to invoke rpmbuild --rebuild knows it because someone told them. Thus, that person is equally able to cut and paste the command I gave. I think most reasonable persons would agree that learning to rebuild SRPMs is easeir then learning to checkout from CVS. I'm not talking about copy and paste, but about understanding what is going on. simply a more limited skillset is required. but your argument is valid and I guess its personal perspective and I will say nothing more :-) Nobody's slinging mud. In my experience, Mandrake is too bleeding-edge for their own good. If it works for you, fine, but you have to acknowledge that problems may be caused by your toolset/distro choice. The same as /you/ have to acknowledge that my problems may be caused by your toolset ;-) Nope. I thought I already explained this. Instead, requiring /usr/include/gif_lib.h and /usr/lib/libgif.so accomplishes the same thing (given a good dep solver) without being distro-specific. Ok. can you do that then, please ? If you refuse to use Mezzanine, you can always add something like this to your script before calling rpmbuild: perl -pi.bak -e 's/\#BuildSuggests/BuildRequires/g' *.spec That would be useful. thanks for the suggestion. I noticed that several spec files do not have the BuildSuggests entry at all or it does not contain the entries that I think it should have. if I test and report on discrepancies between whats written and what is actually required, will you take a look at adding more information to the BuildSuggests entry ? I thought that I can make a dist ball just by running the auto-tools, and packaging the CVS directory after that. can you please explain what's wrong with this approach? CVS directories and other junk end up in the tarball. Not if I do an export. in any case - I always assumed that the tarball/source RPM is a clean snapshot of the source, a.k.a. CVS snapshot/branch. Also the tarball's top-level path does not include the version number, which is a big no-no in most cases. I dont understand why, but I'm willing to accept it. I'm currently handling that in the script I'm writing. I think that packaging the CVS dir as it comes out of the CVS and building off that is the ultimate goal and I sometimes do that. That would be unfortunate. You're better off invoking autogen like this: make maintainer-clean ./autogen.sh --enable-maintainer-mode make dist If I understand correctly. maintainer-mode is evil (or so it is written). but I see your point. thanks. I am in frequent contact with Jeff Johnson (RPM lead developer) and have yet to hear of any such standard, but perhaps I just missed it. Not standard. more of trying not to break things which other people did :-) Since you seem rather opposed to any build tools other than what you're already used to, Actually - what everyone has. if you want to have your software to built out of CVS, then you need to accept that most people will have only the standard tools that came with their distro (and then only those that sits nicely under the label you need this to develop and build software. if you think that everyone that builds out of CVS should have Mezzanine, then please note so in some sort of documentation (and I don't consider the mail archives of the user list to be documentation). Thanks for all the info. I'll take a look at what you've wrote and either integrate this somehow into my system or follow your advice and just use Mezzanine. I can certainly say that I've learned quite a few new things in this thread :-) -- Oded ::.. Many people lose their tempers merely from seeing you keep yours. -- Frank Moore Colby --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ enlightenment-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] can't get embryo_cc to work
On Tue, 2004-07-27 at 18:43, Michael Jennings wrote: On Tuesday, 27 July 2004, at 03:26:34 (+0300), Oded Arbel wrote: I really appriciate the effort of supplying valid spec files in the CVS - its make life so much easier for distributions and other packagers. I wish that more projects will follow. I'm not so sure I agree. Many software developers do not know how to make correct spec files. I can't even begin to count the number of projects I've run into where the spec file was out-of-date, incorrect, or just plain nasty. I try very hard to make good, clean, portable spec files, and I've been doing it since around 2000. At worst we're no worse off then w/o spec files at all, and we can offer fixes. at best we have less work to do :-) In fact, for the entirety of EFL (save perhaps emotion), I can build RPM's by running the following in each directory: ./autogen.sh make dist mzbuild The mzbuild command is part of Mezzanine (http://www.kainx.org/mezzanine/) and makes lots of things about building and maintaining packages a *lot* simpler. If you don't have mezz and don't want to use it, this will do something quite similar to mzbuild in the above command: rpmbuild -ba --define _sourcedir $PWD --define _specdir $PWD \ --define _topdir $PWD --define %_srcrpmdir $PWD \ --define _rpmdir $PWD That's mighty useful, I didn't know about that. I still think that SRPMS are more useful then CVS for building distribution packages as they are less steps involved. specificly there are people who don't know a thing about CVS but can manage a simple rebuild command. - edje: autogen.sh does not work. It works quite well for me as of 3 days ago, so I'd be surprised if it's not valid bash. More likely a problem with your distro. Mandrake is notorious for instability. Please don't go mud-slinging. I've been using Mandrake for over 5 years w/o major problems and in the last couple of years w/o any problem. I can say the same for almost any distro you choose (excluding of course RedHat 6.x and distro with the same outdated software, i.e. debian latest stable), but I won't. It was a problem with my script. I'm sorry I didn't found it earlier. it modified autogen.sh and didn't do it correctly. sorry for bothering. - imlib2 does not build - it fails finding any files for the imlib-loader_gif sub-package. Probably because you don't have libungif-devel installed. Thanks - that did the trick. can you please add libungif-devel as BuildRequires for the imlib2 spec file ? - imlib2_loaders does not have a spec file - it has a spec.in file. is the spec file supposed to be generated by the configure scripts ? that's kind of useless as configure is supposed to be run from the spec file. This must've been an oversight on my part. The spec file I use can be found via CVS at :pserver:[EMAIL PROTECTED]:/var/cvs in caos/users/mej/imlib2_loaders/F/imlib2_loaders.spec Thanks. is it possible that it be put in the e17 CVS like the rest of the spec files ? - I failed to build etox, but I don't think its RPM specific. I'll investigate more and write about it later. Building RPM's from CVS still means that you need all the prereq's. Although if you use Mezzanine and set your hint-installer variable to yum -ty install it will auto-install all buildreq's for you. I don't use Messaine and I don't use yum (I have used it several times, including as recent as FC2, and I still think urpmi is way better). see below. - In all the libraries, autogen.sh by deafult runs configure (while the comment above it implies that it is commented out, which is not the case). autogen.sh is needed to generate the configure script and other such tools. .. you can simply run make dist followed by rpmbuild/mzbuild. I thought that I can make a dist ball just by running the auto-tools, and packaging the CVS directory after that. can you please explain what's wrong with this approach ? The problem I'm having (IMHO anyway - it may all be just in my mind) is that running configured/make and friends changes a lot of files in the CVS dir, and thus making the next build only as clean as make distclean can make it - which is as usall an error-prone process. I rather build stuff out of as clean as dist as possible, with the least ammounts of steps that can go wrong. I think that packaging the CVS dir as it comes out of the CVS and building off that is the ultimate goal and I sometimes do that. The problem with BuildRequires is that they aren't distro-portable. And because missing BuildRequires are fatal (rpmbuild will die without them, even if they're not strictly needed), There are ways to add BuildRequires in a way that is not (or at least - as little as possible) distribution dependant. there are efforts to solve the last remaining cross distribution dependency problems. I don't think its fair to assume that just because something was broken in the past
[e-users] problem building etox from CVS
Hi. As mentioned in a previous email , I'm having some problem building etox from CVS. when trying to build, it starts linking etox_test , and then shows the following errors: gcc: /usr/lib/libfreetype.a: No such file or directory gcc: /usr/lib/libjpeg.a: No such file or directory I have libjpeg62-devel-6b and libfreetype6-devel-2.1.8 installed, and the following files are found in the system: /usr/lib/libjpeg.la /usr/lib/libjpeg.so /usr/lib/libfreetype.la /usr/lib/libfreetype.so If I understand correctly, .la means its a libtool built library file, and I can clearly see that etox is being built and linked using libtool. Other libraries build just fine. I tried to trace the build process but didn't came with anything conclusive. can someone please comment on what might be my problem ? Thx. -- Oded ::.. There is no reason anyone would want a computer in their home. -- Ken Olson, president, chairman and founder of Digital Equipment Corp., 1977
Re: [e-users] can't get embryo_cc to work
On Tuesday 27 July 2004 02:38, Michael Jennings wrote: On Monday, 26 July 2004, at 23:26:25 (+0200), Andreas Volz wrote: And if the the questioner has a RPM based distribution you could perhaps use gentoo's feature to create RPM's with ebuild. I wonder why nobody yet uses this feature from gentoo to create (unofficial) RPM packages from E17 CVS? Because the resulting packages would be completely useless. There's a reason you can't necessarily use FC2 RPM's on a RH9 box and vice versa. Gentoo, Debian, and any other system capable of producing RPM's has the same problem. The spec files for all the EFL libs are clean and working. RPM's are easy to build, no Gentoo required. I really appriciate the effort of supplying valid spec files in the CVS - its make life so much easier for distributions and other packagers. I wish that more projects will follow. I'm trying to build RPMs from CVS for my system (Mandrake 10). actually - I'm writing a script that will allow to build E17 CVS and install it as RPMs directly. the resulting RPMs will of course be useless for anyone not using Mandrake 10, but the source RPMs generated will be useful to build the specific CVS snapshot on other systems - much more so then checking out of CVS would ever be. Now - I'm having some problems with doing so, which makes me think your last decleration may not be so true (especially the easy part). specificly I'm currently stuck with these problems, and I do hope someone can comment on how I can resolve this issues: - edje: autogen.sh does not work. the autogen.sh script looks nothing like the scripts for the other libraries, and bash complains about all the curly braces in the checks in the front. I can't tell what the problem as I'm not familiar with this syntax - I don't even think its valid bash. The m4 directory is also missing. - imlib2 does not build - it fails finding any files for the imlib-loader_gif sub-package. - imlib2_loaders does not have a spec file - it has a spec.in file. is the spec file supposed to be generated by the configure scripts ? that's kind of useless as configure is supposed to be run from the spec file. - I failed to build etox, but I don't think its RPM specific. I'll investigate more and write about it later. Also, issues general to all the libraries: - In all the libraries, autogen.sh by deafult runs configure (while the comment above it implies that it is commented out, which is not the case). as the order of building RPMs (AFAIU) is - autogen, rpmbuild (which runs configure, make and make install), that step is redundant. I currently solve this by automaticly fixing the autogen.sh script in my build process. - All the spec files are missing BuildRequires tags that are needed to force a build order - other wise users can try to build packages out of order and fail. the BuildRequires tag is supposed to help users by letting them know what they need before spending a lot of times (sometimes a couple of hours) on a build that would fail. I haven't tried to compile all the libraries as I got stuck on imlib2 and edje which most other libs depend on. -- Oded ::.. X windows: Putting new limits on productivity. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click ___ enlightenment-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
