First: Thanks A LOT for all the efforts you put into Equinox and especially for keeping the project alive even when it was abandoned by the others!
I've added Equinox the the Arch Linux wiki just a few days before since it really mentioned most DEs with just EDE missing. You can have a look at it here, if you want: https://wiki.archlinux.org/index.php/Equinox_Desktop_Environment. In case there's anything wrong or missing, just tell me and I'll correct or add it.
BTW: I have no idea if you know it (who can keep track of all distros out there?), but on Arch EDE2 is available from the "Arch User Repository" which means that installing EDE is as easy as downloading two PKGBUILD files (edelib and ede), issuing the "makepkg" command and then install the packages. This is surely the next best thing to having pre-compiled binary packages available and certainly better than nothing (especially since even huge distros like Debian know nothing of Equinox!).
In my free time I sometimes like tinkering with older computers and while I also feel rather confortable with a console system or X + some WM, setting up a very frugal DE to get a "real desktop system" is a very nice challenge.
I've been using Linux (again) for some years now and finally kind of feel at home. However there's of course always some things which a user dislikes. Fortunately on Linux we can change things if we don't like them - and if we know how to do it. I had the idea of "starting a new distribution" (for learning purposes!) for quite a while as I feel that you learn the most if you actually do something. Having not too much inside knowledge of Linux and above all being no coder ( :( ), I hesitated to do it. But this is where Equinox came in!
While I can't remember when I found out EDE existed, I remember well that I thought it was dead due to the long time 2.0 remained beta and there was no development visible for me. "What a pitty!" I thought. It's not hard to guess how much I was surprised in May when I read on a German Linux news site that EDE 2.0 final had been released! At first I had a lot of trouble getting it to work (I failed on Gentoo and some other distros) and when I finally had EDE start on one box, the configuration didn't work. Yet I was and still am impressed by this DE - and by the fact that it's based on FLTK!
I think that LXDE for example is not a bad DE at all - but GTK+ is just way too fat if you ask me (not to even talk about Qt). I wondered if a GTK+-less and qt-less **desktop system could be built. Equinox answered the question: Yes - at least in theory. There are not too many FLTK programs available and the "FLTK Apps" project seems to go nowhere. In June I decided to just start my project. The primary goal is to learn a little more about the depths of GNU/Linux and the long-term goal to develop a "light-weight desktop distribution". The first one can't possibly fail and if the second goal is never achieved - well, it's ok, too.
Now I wonder what you as the developer of Equinox think about it: Some kind of test distro that tries to do without GTK+ and Qt and using EDE2 as its standard DE. Do you think there would be people interested in such a thing? The biggest problem would likely be standard applications. However I found that TinyCore have developed two FLTK-based file managers for example. Together with programs like MuPDF which don't require any toolkit at all, it *might* be possible to put together something like a FLTK/EDE2 desktop distribution! Of course many people will prefer Firefox or at least Midori over Dillo - but that's another story and far beyond the scope of this effort.
Anyway: Great work with EDE2! Please keep on improving it - it is very much appreciated.**
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for positive feedback! And thank you for filling Arch wiki
about EDE.
> I have no idea if you know it (who can keep track of all distros out
> there?), but on Arch EDE2 is available from the "Arch User
> Repository" which means that installing EDE is as easy as
> downloading two PKGBUILD
Didn't know this. Thanks for posting it. Can you write a little howto
for Arch, so I (or you if you find some time) can put it on wiki?
> I remember well that I thought it was dead due to the long time
> 2.0 remained beta and there was no development visible for me.
True, 2.0 development had it's problems, but now the things should go
smoother. This almost always happens when you are doing rewrite from
the scratch :D
> the configuration didn't work
Yes, I'm aware of this. However, I'm hoping configuration will be make
easier (and documentable) for 2.1 or 2.2 release.
> Now I wonder what you as the developer of Equinox think about it:
> Some kind of test distro that tries to do without GTK+ and Qt and
> using EDE2 as its standard DE. Do you think there would be people
> interested in such a thing?
Sure! For example, Minix community is a big 'no bloat' fan and Qt/Gtk+
aren't even in standard distribution. That is why I'm trying these
days to revive Minix port because previous EDE versions were quite
popular on it.
Also distros like TinyCore and Puppy are always welcoming something
done with FLTK. Since Minix, TinyCore or Puppy are still alive, tells
you enough how people are using it :D
I'm aware how file manager is, for now, big obstacle; one of previous
EDE developers started file manager project, but it isn't completed.
Maybe I revive it at some point, but my main priority for now is to
improve EDE portability and translation support.
For now, I will for sure recommend Fluff (TinyCore file manager);
AFAIK it is still actively developed.
> Of course many people will prefer Firefox or at least Midori over
> Dillo - but that's another story and far beyond the scope of this
> effort.
True; IMHO the main Dillo drawback (at least for me) is missing any
kind of javascript support: modern web pages are often unusable
without it and even basic javascript interpreter with mediocre speed
could improve the situation. Other than that, I'm considering Dillo
much superior than any browser out there ;)
Let me know about your progress.
Regards,
Sanel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can you write a little howto for Arch, so I (or you if you find some time) can put it on wiki?
Sure! I'm going to write one tomorrow.
Oh, something else: i686-binary packages for Arch Linux are just ~410 KB (edelib) and ~12 MB (ede) in size. I don't know what the hosting conditions of http://equinox-project.org/ are, but maybe even a custom repository could be set up. This would mean that an Arch user who wants to test EDE2 only had to add two lines to the .conf of his package manager and can simply install the DE afterwards just like any other package. If you're interested in it, I can also try to build x86_64-packages and look into how custom repos work (haven't been using Arch for long). That way anybody could give EDE a try without having to compile anything. I'd also volunteer to try and build updated packages if you release a new version (at least for the forseeable future).
my main priority for now is to improve EDE portability and translation support.
That's great! Another important plus for EDE. I had previously tried to build a package for Alpine Linux. Right, usually nobody knows this, but I think that it's an interesting distribution (meant for embedded systems) being based on Busybox and µclibc instead of glibc. They managed to have Xfce (!!) run with ~40 MB of ram! Interested in just how small it gets, I wanted to try EDE, but while I was able to build binary packages for FLTK, ftjam (the distro does not come with too many packages available) and edelib, I wasn't able to solve my problems with the ede package. If I remember correctly, it was pekwm which didn't want to compile (or be linked). I dismissed this experiment, since µclibc is probably a very special case… But since you write that you are interested in portability (and EDE is well fit for embedded hardware) - are you interested in getting EDE to run on such a system, too? If so, I'd try to repeat my testing as time permits and post the error messages here.
In terms of translation I can also offer a little help: I can do (some) proofreading of English texts and can translate things to German if needed.
For now, I will for sure recommend Fluff (TinyCore file manager); AFAIK it is still actively developed.
Yes, Fluff is probably the best choice for an FLTK fm. I know it from TinyCore, but I have not been able to get it to compile on Arch, yet. I'll have to take a look at that again sometime.
True; IMHO the main Dillo drawback (at least for me) is missing any
kind of javascript support: modern web pages are often unusable
without it and even basic javascript interpreter with mediocre speed
could improve the situation. Other than that, I'm considering Dillo
much superior than any browser out there ;)
I totally agree: Dillo is fantastic for what it is. Problems are really the missing js support and the very bad html style that can be found just about everywhere on the net… But the Dillo developers already got pretty far with their browser. I'm quite positive that it will continue to improve, making it a real alternative.
Let me know about your progress.
I will. On Monday I'll post a link to my blog with the desktop test results (I compared ~20 Linux desktops, of course including EDE2).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Oh, something else: i686-binary packages for Arch Linux are just ~410
> KB (edelib) and ~12 MB (ede) in size. I don't know what the hosting
> conditions of http://equinox-project.org/ are, but maybe even a custom
> repository could be set up.
I can arrange something. The hosting space is precious as hosting is
donated, but if you decide to continuously maintain the packages, we
could make mixed repo for Arch/Fedora/… on a single place.
> build a package for Alpine Linux. Right, usually nobody knows this,
> but I think that it's an interesting distribution (meant for
> embedded systems) being based on Busybox and µclibc instead of
> …
> I was able to build binary packages for FLTK, ftjam (the distro does
> not come with too many packages available) and edelib, I wasn't able
> to solve my problems with the ede package. If I remember correctly,
> it was pekwm which didn't want to compile (or be linked).
> …
> are you interested in
> getting EDE to run on such a system, too? If so, I'd try to repeat
> my testing as time permits and post the error messages here.
Absolutely! Can you please try it again and post pekwm errors here? I
always wanted to check how uclibc (and others minimal libc versions)
will work with EDE :)
> In terms of translation I can also offer a little help: I can do
> (some) proofreading of English texts and can translate things to
> German if needed.
Sure! Wiki already have support for browser specific languages, so
people for which German is native will automatically get German texts.
> I will. On Monday I'll post a link to my blog with the desktop test
> results (I compared ~20 Linux desktops, of course including EDE2).
Please drop me a link when you do so.
Regards,
Sanel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can arrange something. The hosting space is precious as hosting is
donated, but if you decide to continuously maintain the packages, we
could make mixed repo for Arch/Fedora/… on a single place.
Are there Fedora packages, yet, or would Arch be the first Distro with EDE2 in a repo? Whatever the case, I guess you mean the way e.g. MATE does it (http://repo.mate-desktop.org/)? I think having a central place where packages for the various distros are kept is a good thing. Is there any other packaging currently going on? If I remember correctly, somebody attempted to bring EDE packages to Debian but has not succeeded so far. Right?
Building a custom repo was even easier than I thought. Here's a tarball with two Arch repos (i686 and x86_64 versions of edelib and EDE2): http://uploaded.net/file/5m69wpx1 I built edelib-2.0.1 for the repo, so it includes the icon fix you published here on the forums.
Depending on where you upload it, installing EDE on arch would mean adding something like the following two lines to the pacman.conf file and then just installing package ede regularly:
This is just a suggestion. If you like e.g. like "" better, things can of course be called differently. Because of the packaging I did not yet write a howto, since if there are binary packages available, it's a completely different situation.
I have another question/suggestion here. Is there a reason that EDE2 consists of only two packages? I would prefer for example if pekWM was seperated and other WMs could be installed alongside EDE2 (and if it was only for testing purposes). But even more important: There's quite a lot of stuff (like all the PNG files) in the EDE package which doesn't really belong there; from the point of view of a packager, it would make sense to take these out of ede2-*-i686* and ede2-*-x86_64* where they mean double ballast and instead stuff them into something like an ede-common2-*any*. What do you think about moving any platform-independant files into an extra package which will be shared on all systems? I guess that this might also be a lot closer to the packaging guidelines of many distros. At least they frequently do this.
Absolutely! Can you please try it again and post pekwm errors here? I
always wanted to check how uclibc (and others minimal libc versions)
will work with EDE :)
Ha, great! I just thought that I shouldn't be wasting your time with something like that - but I see we have a common interest in… unusual stuff. I'll definitely let you know when I got there again.
Please drop me a link when you do so.
I'd love to, but SF won't let me. Whenever I try to post a reply that contains the name of the blog, it rejects it as "spam". I'm sorry that things are so cumbersome - but the blog's called "Eerie Linux" and is hosted on Wordpress. Please go there yourself and click on the "Overview of posts" link on the right side. It's blog entries 13. and 14. that deal with EDE.
Another testing series is planned for the future: I'll try to compare the amount of memory needed while doing a range of common tasks (browsing the web with 3 tabs, viewing a pdf, etc.) and I have a feeling that EDE + FLTK-Apps will easily win - IF I manage to find FLTK-based tools for every job (and get them to run).
I'll keep posting here when I have something about EDE (like an Arch-based live-CD which I also plan to create once I get some FLTK tools running).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for posting. I'll try to setup it in upcoming days and let you when is done :)
> Is there a reason that EDE2 consists of only two packages?
Agree, things like images and icons could be in separate package. However, the main idea
is to have as less packages as possible; it is much easier, especially for novice users. On other
hand, distros can repackage installed programs and stuff as they like.
But, if this proves to be unsuitable in future, I'll try to split them for sure.
Btw. I checked your blog posts; good work and read! And thank you for positive feedback :)
> I'll keep posting here when I have something about EDE
Of course. Always glad to hear that.
Regards,
Sanel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'll try to setup it in upcoming days and let you when is done :)
Great to hear that you'll set up the repo! I'll happily test it once it's ready.
On other hand, distros can repackage installed programs and stuff as they like.
That's true of course. Packaging uses fakeroot and "make install" (or "jam install" in our case) to build the package. However I can also copy the needed files manually, this is no problem. Which directories and/or files do you think should be stuffed into the ede-common package? Both packages will compile the whole thing that is in the ede-2.0-tar.gz source package, I guess, but I don't really mind that. For the actual ede package, I'd then just remove the files that are already in the common package from fakeroot folders and add ede-common to the new package's dependencies.
Well, and perhaps the WM could also be separated from the main package. Right now it's conflicting with the pekwm package that's available separately. I'd prefer control over simplicity. Also if we have a repo, it doesn't make a difference for the end-user if two packages are installed or four - more on the contrary actually: If somebody has pekwm already installed, ede will refuse to install as it is currently! If the wm was separate, that case would no longer be a problem.
I also found some time to install a fresh Alpine Linux today and build packages for fltk, ftjam and edelib. These are working well. Just as I wrote before, building the ede package fails because pekwm can't get linked. To get a bit closer to the problem, I tried if pure pekwm could be built, but it also fails.
I tested pekwm version 0.1.15 with makedepends "jpeg-dev, libpng-dev, libiconv-dev, libx11-dev" and no configure options except for setting the prefix.
And if I try to build ede with makedeps "fltk ftjam autoconf automake dbus-dev libx11-dev jpeg-dev libpng-dev zlib-dev libxext-dev libiconv-dev" and no configure options except setting the prefix, these are the lines I think may be relevant:
How are things going? I don't know if you're just very busy or if you missed my last post (with the packaging attempt on that µclibc-based distro).
Anyways, in the meantime I thought that I might well try something different and take a look at writing Gentoo ebuilds. I wrote one for edelib and got quite far with that. It downloads all the dependencies, builds the configure script, runs it and compiles edelib. Only the last step, packaging itself, fails.
The problem here is that jam DESTDIR="${path}" install works well for all files - except the docs. Everything gets installed to /var/tmp/portage/x11-libs/edelib-2.0.r-0/image//usr/bin/ (i.e. the fake-root, I think). Only for the docs, jam wants to create /usr/share/doc/edelib-2.0.0 and copy README, INSTALL and so on there. Portage prevents this and fails with an access violation.
I've taken a look at the Jamrules file for example and found where EDELIB_DOCDIR is set. I changed that in the ebuild with sed, but unfortunately this is really just the name of the doc dir and won't let me change the absolute path. I'm at my wits' end here, especially since I don't know how jam (or even makefiles) really work.
Do you have any idea why the documentation behaves so differently in comparison with the rest of the files? If we could fix this together, I'd try to create an ede2.0 ebuild as well. And if everything works, I can look into building a portage overlay from it so that Gentoo would be another platform to easily use EDE on. Of course I can write a short tut afterwards.
BTW: What's the Arch repo thing doing? I wanted to write a tutorial on that, too, once it's available.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for pinging me. True, I was quite busy last two weeks and I'm restarting development again. I'll check what needs to be done and let you know when is completed (hopefully today).
Regards,
Sanel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Related to that pekwm issue, have you have iconv installed? Looks like I'll have to put it as optional, since glibc is providing builtin iconv implementation.
> The problem here is that jam DESTDIR="${path}" install works well for all files
Did you used 'jam DESTDIR=<path>'? You have to use it as:
jam -sDESTDIR=<path>
with '-s' option, so jam can recognize it as variable. Works?
Regards,
Sanel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Related to that pekwm issue, have you have iconv installed?
Yes, I installed a seperate package "iconv" but it seems not to provide the expected function. Hm. If I remember correctly, Alpine tries to keep things slim and configuring programs not to build all optional features. I might try to remove the "iconv" package and compile one myself on my test system - perhaps that'll do. If not… Well. I'll post again. ;)
with '-s' option, so jam can recognize it as variable. Works?
Unfortunately: No. It doesn't seem to make any difference. Like before, jam puts everything in the right directories except for the docs. It still wants to create a directory in /usr/share for them…
But I've also got some other news: I registered on EDE's wiki system today. I'm not really getting along well with it, yet (I'm used to the default, full-blown MediaWiki) but I've edited the FAQ page (just a few corrections). Would be nice if you find the time compare it with the latest revision before the changes and tell me wether you like it. If you do, I can offer some proofreading.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yesss! It's working! I just tested both 32-bit and 64-bit on new Arch VMs. So at least on Arch installing EDE2 does no longer involve any compiling. A nice step ahead! :)
I'm going to post it on the Arch forums and ask for feedback there. If all goes well, I'll add it to the wikis and afterwards you can perhaps write a newspost for it? The latest one is rather old by now and for the reader it would certainly give a better impression if "there's something going on" with the project.
Please add on the bottom of edelib-src/Jamrules the following code:
actions quietly MkDir1 {
mkdir -p $(<) ;
}
(please note the space before ';' as it is part of jam syntax. Now can you please remove /tmp/portage folder and recompile and install it again? Works?
Regards,
Sanel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Arrg! "Sorry, the text entered looks like spam and cannot be posted." Again! I have no idea how to get along with that properly… I'll try to post it without the ebuild and abuild files.
For Gentoo: I don't know whether it's a typo again, but Gentoo uses FTJam 2.5.3(-rc2). I tried adding your three lines using echo and sed, but - again - it unfortunately doesn't make a difference.
I've read your bug tracker entry and I don't think that it's a general FTJam issue but rather a Gentoo specific (?) one. On both Arch and Alpine FTJam is used to build edelib and ede and there seems to be no problems (the "-s" option is missing on the Arch PKGBUILD, btw.). For that reason I took a look at Gentoo's FTJam ebuild - it seems apply several patches.
Perhaps this can give you any clue? Here's the content of the file ftjam-2.5.3_rc2-r1.ebuild:
BTW: With the version haiku-jam that you offer here on SF, packaging works well! I downloaded and compiled it on my Gentoo test system, copied the jam executable into the source dir and changed the jam command in the ebuild to ./jam. That installs the docs to the right place and the edelib installs correctly. If all else fails, this could be a last resort way to get things done.
Alpine: I've taken a look at the iconv ABUILD and what I expected is not the case. But I'll post the content of the APKBUILD, anyway:
Arch: Over 170 people have clicked the thread that I created, but so far nobody has posted anything about the packages. Let's see if that changes in the next few days.
Other things: I've build another testing VM with Arch and FLTK1.1.10. Edelib and EDE work well and thanks to a friend of mine I could get Fluff to compile with that version. Same goes for some other FLTK applications that would be nice/important to have for the experimental distro. However Dillo needs FLTK1.3 and is of course completely indispensable. :(
With Fluff being still in development, I think chances are that it'll eventually get ported over (probably not before TinyCore switches to FLTK1.3, though). For most of the other projects that'll most likely not be the case. What do you think about installing both FLTK versions on the same system? Like 1.3.0 installing normally and 1.1.10 into /usr/lib/fltk11 or anything like that? A stopgap for sure, but perhaps an option to get things started at all.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry for late reply; I was on trip back home from conference…
> Perhaps this can give you any clue? Here's the content of the file
> ftjam-2.5.3_rc2-r1.ebuild:
Hm… how about filling a ticket to gentoo devs? If all jam versions
(stock, ftjam and haiku) are working, except that version with
patches, probably those patches are making some issue?
> Arch: Over 170 people have clicked the thread that I created, but so
> far nobody has posted anything about the packages. Let's see if that
> changes in the next few days.
Nice!! Maybe they didn't find any issues installing it :D
> What do you think about installing both FLTK versions on the same
> system? Like 1.3.0 installing normally and 1.1.10 into
> /usr/lib/fltk11 or anything like that? A stopgap for sure, but
> perhaps an option to get things started at all.
Sure, this can work. I have the same setup, where I keep 1.3.0 in
/usr/local and 1.1.10 in /opt/fltk11. Just make sure Fluff catch
fltk-config in /opt/fltk11 before the one in system folder. You can
do this by exporting PATH variable like:
export PATH="/opt/fltk11/bin:$PATH"
Or, Fluff maybe have option to manually specify fltk-config path.
PS: what you would like me to do with those buildfiles; replace them in arch repo?
Regards,
Sanel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hm… how about filling a ticket to gentoo devs? If all jam versions
(stock, ftjam and haiku) are working, except that version with
patches, probably those patches are making some issue?
You're right, I'm going to ask in the forums once I find the time for it. Maybe someone will care!
Nice!! Maybe they didn't find any issues installing it :D
The only thing I think should be corrected with the packages in repo is that EDE was "compiled without XKB extension". I guess that this is due to myself compiling them on a bare system which had no packages installed but those that were real dependencies. Could you tell me please which packages should be added to the deps so that EDE is fully functional (without the very useful feature to change keyboard layout easily, it's crippled unnecessarily)?
Oh, and would you also tell me which files from the EDE source package you think could be packed into a new binary package ede-common? Since I have to rebuild the packages again before the announcement anyway, I might as well do things right from the start. I took a little time to skim-read some of the packaging documentation for DEB and RPM packages. The packaging guidelines are quite strict and the whole thing is rather complex. But if anybody ever wants to provide packages for systems like Debian or SuSE, we really should split things. At least for official packages it's even a requirement and for unofficial ones probably still "bad style" if we don't.
(I can't promise anything, but I might dig a little deeper into packaging on various distros to make EDE a little easier to access and hopefully better known.)
Sure, this can work. I have the same setup, where I keep 1.3.0 in
/usr/local and 1.1.10 in /opt/fltk11. Just make sure Fluff catch
fltk-config in /opt/fltk11 before the one in system folder.
Thanks for the tip! I'll mess with it a little - and who knows, perhaps something usable will come out.
PS: what you would like me to do with those buildfiles; replace them in arch repo?
No, these are the build files for FTJam on Gentoo and for Iconv on Alpine. In the FTJam one you can see what patches are applied - but you're right. This issue is not actually your problem and I'll ask the Gentoo guys.
On the µclibc-based distro I'm not getting EDE (or Pekwm) compiled and it does not seem that the iconv package was crippled in any way. The build file should give you an idea which version is used on Alpine and if the particular version is fit for the routines needed by Pekwm.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> The only thing I think should be corrected with the packages in repo
> is that EDE was "compiled without XKB extension". I guess that this
> is due to myself compiling them on a bare system which had no
> packages installed but those that were real dependencies. Could you
> tell me please which packages should be added to the deps so that
> EDE is fully functional (without the very useful feature to change
> keyboard layout easily, it's crippled unnecessarily)?
Aaah yes, I almost always forgot about this extension… You will need
libxkbfile (and libxkbfile-devel if distro split development and
ordinary libraries). AFAIK, beside X packages, you will need mentioned
XKBfile and XShape extensions, libxpm and curl. The rest is mentioned
on wiki (hoping I didn't forgot anything else).
> Oh, and would you also tell me which files from the EDE source
> package you think could be packed into a new binary package
> ede-common?
Sure. I would put ede.desktop, icon-themes, menu, mime-types, pekwm
and wallpapers found in 'data' folder. Be aware how 'ede.desktop' must
go in session manager folder (usually in /usr/share/xsession), no
matter where ede was installed. This depends on used session manager
and it's configuration, but I always put in mentioned folder.
> But if anybody ever wants to provide packages for systems like
> Debian or SuSE, we really should split things. At least for
> official packages it's even a requirement and for unofficial ones
> probably still "bad style" if we don't.
Yes, I know how they keep things a bit complex and big 'Thank You!' for
investigating this field :)
> On the µclibc-based distro I'm not getting EDE (or Pekwm) compiled
> and it does not seem that the iconv package was crippled in any
> way. The build file should give you an idea which version is used on
> Alpine and if the particular version is fit for the routines needed
> by Pekwm.
Hm… can you add '-liconv' option to pekwm Jamfile; just scroll to
the bottom of pekwm/Jamfile and modify line:
and try again. If iconv is located in different folder than /usr/lib
(you can check it with 'ls -la /usr/lib/libiconv*'), like
'/usr/local/lib', just modify above line to:
This iconv thing is probably the major issue with pekwm because it
is quite unportable among OS-es, even if it was designed
otherwise. I'll try to address it in next versions, but for now it
must be present to allow proper utf8 conversion.
Let me know what gentoo crew replied :)
Regards,
Sanel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
AFAIK, beside X packages, you will need mentioned
XKBfile and XShape extensions, libxpm and curl.
With XShape you mean Xext? I've built new Arch packages on sunday but have not included that one as a dep. Had issues with invisible mouse cursor, too, so I'll have to take a closer look when I come home tomorrow.
Beside that, I've split the packages like this: edelib is untouched (or should I add some optional deps there, too?). Ede now only contains everything that goes into /usr/bin and the shared objects in /usr/share/ede/panel-applets. Then I made a ede-data as you suggested (do you like 'data' more than 'common'? I think both are in use out there) and put the rest of dirs in there, except for the wallpapers that are seperately put into ede-wallpapers.
Package ede depends on both edelib and ede-data now and has an optional dependency on ede-wallpapers which is suggested for installation but not needed. While I like the wallpapers (especially the winter night one) they are pretty high-res and rather big. All EDE packages together are still ~12.3 MB in size but leaving out the optional wallpapers, the size is cut down to 5.2 MB! I wish I had known this eariler (for the results of the DE tests on my blog)! ;)
I also renamed the repo database to , since there seems to be more software that goes by the name "equinox". What do you think about these suggestions? If you're happy with them, I'll try to get the new packages built and uploaded tomorrow evening.
Yes, I know how they keep things a bit complex and big 'Thank You!' for
investigating this field :)
You're welcome! I said that I wanted to help and since I'm limited to non-coding tasks, this is probably something that I can actually do.
Hm… can you add '-liconv' option to pekwm Jamfile;
That sounded reasonable, I had to try it right away. Result: Success! I also added -lXext to ede-desktop and building the package works with no more errors now! Thanks for the tip!
However the machine I built this on is not capable of running X today (some ancient VIA graphics chip that makes unichrome crash with segmentation fault and xf86-vesa also not working for whatever reason) even though it has worked in the past (SuSE 7.0 around the year 2000). So I can't test EDE right now, but I'll tell you as soon as I can. I'm VERY curious how little RAM will be needed! :)
BTW: A friend visited me last weekend and I showed him FLTK. He didn't know it before but liked it. Result of a little playing around: I have a working Fluff package for Arch now that works with FLTK 1.3 and has a TinyCore specific feature removed. He also got some more FLTK apps working that I was having trouble with. I think I'll have a first "alpha-preview" of what gave this forum thread its name working soon. I'll let you know.
Oh, and another thing: Since I've been actually using EDE on my old laptop, I've found a few bugs that I wanted to report. To see if they were already known, I registered on the bug tracker but I can't use it. Currently I only have Chromium available for browsing and whenever I click on either ede or edelib and then select "general", I get a 404 ("The requested URL /bugzilla/bugzilla/buglist.cgi was not found on this server."). Is it only me or is there something wrong?
Let me know what gentoo crew replied :)
Of course, I will. However I thought that I might do a little more tinkering first. I'll edit the ftjam ebuild and disable the patches to see if it works then. Perhaps I can find out which patch (or which combination) breaks it. Being able to provide more information will increase chances to actually get this issue resolved, I guess. But even if it ends with a "won't fix", I'm pretty sure now that I'll come up with a more or less ugly workaround. I'm still determined to bring EDE to Gentoo, too! *g*
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Like I wrote in my last post, I hope that Xext is what you suggested adding. I've solved the problem of the missing cursor by rebuilding edelib, too, with some of the deps added as well. I've build new packages (the way I described above) for both platforms and uploaded them. You can download the tarball here: http://www.file-upload.net/download-6821974/archrepo.tar.html
In case of the build on Alpine: While the package was successfully built, it does not work completely. When I start X, ede obviously launches pekwm but then I'm left with just the one color background and nothing more. I've added a terminal emulator to be started, too, so I can have a look at what happens.
I can excute most programs that come with EDE (like e.g. ede-about) but starting the panel does not work. This is what gets printed to the console:
Do you have any idea where to add this before building the package again?
About the bug tracker again: It seems to be seriously broken for some reason. The problem I encountered is not browser specific. I tried again with Firefox but whenever I log in, click "browse" and select any category (doesn't matter if it's 'ede', 'edelib', 'efltk' or 'www') the next page only offers me 'general' which leads to a 404 (/bugzilla/bugzilla/buglist.cgi not found). Probably it's a problem with the double directory ("/bugzilla/bugzilla")?
And one more news: I've released the first alpha version of a project that I call "Desktop Demo DVD". Its goal is to provide a live medium with a graphical login manager where a bunch of desktop environments (or better: All that I can get to run) can be selected and easily tested. This early version provides 5 DEs - among them, of course, EDE (the other ones being: MATE, Xfce, LXDE, Enlightenment 17).
I'm not sure yet what people think of it and if I should continue the project. But if it shows that there's interest in it, it could lead to people getting to know the less well-known DEs, too. In any case, EDE is in there right from the beginning.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oh crap!!! I made reply on your post, but it disappeared #@#!!
Sourceforge from time to time eats these forum posts… If I don't
reply you in day-two, please mail me or post comment on my blog.
Sh*tty hosting…
> Like I wrote in my last post, I hope that Xext is what you suggested
> adding. I've solved the problem of the missing cursor by rebuilding
> edelib, too, with some of the deps added as well.
True, Xext is the extension.
I'll try to remember what I replied you for previous post…
> Then I made a ede-data as you suggested (do you like 'data' more
> than 'common'? I think both are in use out there) and put the rest
> of dirs in there, except for the wallpapers that are seperately put
> into ede-wallpapers.
Excellent; only I suggested you put content from 'data' folder in it,
and is fine to keep the name under ede-common, but if you like
'ede-data', fine with me ;)
> All EDE packages together are still ~12.3 MB in size but leaving
> out the optional wallpapers, the size is cut down to 5.2 MB! I wish
> I had known this eariler (for the results of the DE tests on my
> blog)! ;)
Good! True, wallpapers are space eaters as they are in high resolution.
> I also renamed the repo database to , since there seems
> to be more software that goes by the name "equinox". What d- you
> think about these suggestions? If you're happy with them, I'll try
> to get the new packages built and uploaded tomorrow evening.
Can it be named 'ede' please? This equinox name is often related to
eclipse project and 'ede' is a little bit less to type and easy to
remember.
> However the machine I built this on is not capable of running X
> today (some ancient VIA graphics chip that makes unichrome crash
> with segmentation fault and xf86-vesa also not working for whatever
> reason) even though it has worked in the past (SuSE 7.0 around the
> year 2000). So I can't test EDE right now, but I'll tell you as soon
> as I can. I'm VERY curious how little RAM will be needed! :)
Me too! Please let me know about the status so I can optimize things
here and there is is needed.
> have a working Fluff package for Arch now that works with FLTK 1.3
> and has a TinyCore specific feature removed. He also got some more
> FLTK apps working that I was having trouble with. I think I'll have
> a first "alpha-preview" of what gave this forum thread its name
> working soon. I'll let you know.
Excellent! Again, let me know about the progress :)
> the problem I encountered is not browser specific. I tried again with
> Firefox but whenever I log in, click "browse" an0 select any
> category (doesn't matter if it's 'ede', 'edelib', 'efltk' or 'www')
> the next page only offers me 'general' which leads to a 404
> (/bugzilla/bugzilla/buglist.cgi not found). Probably it's a problem
> with the double directory ("/bugzilla/bugzilla")?
Ahh, yes, it is the problem with our hosting; at the beginning we had
perfect bugzilla setup, but hosting got messed up with various
updates; just remove all 'bugzilla' parts in url and you will get it
working.
However, if you had curl installed when you compiled EDE, you can use
ede-bug-report tool, which will post issues automatically on
bugzilla. The downside is that you will not get updates when I comment
on issue, but I will contact you via mail is something is needed.
> And one more news: I've released the first alpha version of a
> project that I call "Desktop Demo DVD". Its goal is to provide a
> live medium with a graphical login manager where a bunch of desktop
> environments (or better: All that I can get to run) can be selected
> and easily tested. This early version provides 5 DEs - among them,
> of course, EDE (the other ones being: MATE, Xfce, LXDE,
> Enlightenment 17).
Congratulations. Can you send me a download link, so I can update
download page with it?
> I'm not sure yet what people think of it and if I
> should continue the project. But if it shows that there's interest
> in it, it could lead to people getting to know the less well-known
> DEs, too. In any case, EDE is in there right from the beginning.
Sure, there will be always interest from people to try something new,
but without hassle of installing, compiling and such stuff. We are
getting lazier every day :D
Oh crap!!! I made reply on your post, but it disappeared #@#!!
Sourceforge from time to time eats these forum posts… If I don't
reply you in day-two, please mail me or post comment on my blog.
Thanks for posting again in this case! We all love SF, I guess… But good to know that it's ok for you to write again as a reminder or in case anything like this happened. I deliberately waited for a little over a week because I didn't want to get on your nerves. ;) So now I know better - and this may speed things up a little!
Excellent; only I suggested you put content from 'data' folder in it,
and is fine to keep the name under ede-common, but if you like
'ede-data', fine with me ;)
Ah, now I see. You mean the stuff that's in folder 'data' in the builddir… I didn't find any such folder when I examined what gets installed by "jam install", so I didn't quite understand. I changed the name to 'ede-common' again, since I feel this sounds more familiar somehow.
Can it be named 'ede' please? This equinox name is often related to
eclipse project and 'ede' is a little bit less to type and easy to
remember.
Yes, of course. That's why I asked you what name you'd prefer. ;)
I rebuilt all packages again including the name change from 'data' to 'common'. Also the repo's database files use the name 'ede' now so that the repo's name will be '' on Arch.
Let me know when it's up; I'll test it one more time then and afterwards prepare a little tutorial for the wiki. :)
Me too! Please let me know about the status so I can optimize things
here and there is is needed.
I can't figure out how to do away with the error message I quoted in the last post. Except for ede-panel everything seems to work (I checked some random executables). Can you tell me in which file I should add the recommended "-fPIC" option? Or is this perhaps not even the right way to solve the problem?
Ahh, yes, it is the problem with our hosting; at the beginning we had
perfect bugzilla setup, but hosting got messed up with various
updates; just remove all 'bugzilla' parts in url and you will get it
working.
Just wanted to try it, but I no longer get this error. Instead my browser keeps on loading - I guess, you're currently working on it so I'll try again later. Thanks for taking care of this so quickly!
However, if you had curl installed when you compiled EDE, you can use
ede-bug-report tool, which will post issues automatically on
bugzilla.
The problem was (or is) that I cannot browse the bugs already reported to know if it's a new issue that I should create a ticket for,
Can you send me a download link, so I can update
download page with it?
Hm. I'm not quite sure if it's worth being put on the EDE site. It's a really early version and hosted on a 1-click hoster. On the other hand I might reach a few more people that way and perhaps find somebody who's interested in helping… Well, I propose you take a look at it if you feel like it and then decide yourself. After all I released it to the public and everybody can do with it as he wants. *g*
However thanks to SF I still can't post a link to my blog… Perhaps if don't mention it directly? I'll try: The adress to the blog is "eerielinux DOT wordpress DOT com". The currently topmost post (#21) is the correct one. You'll find a download link there as well as the md5sum of the iso, the password for the login and some more information like that.
Next I intent to dedicate my time to Gentoo again (or perhaps Alpine if the problem I ran into is not a big one).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> You mean the stuff that's in folder 'data' in the builddir… I
> didn't find any such folder when I examined what gets installed by
> "jam install", so I didn't quite understand. I changed the name to
> 'ede-common' again, since I feel this sounds more familiar somehow.
Yes, in builddir, but I forgot that package will pick installed
folders, not those from where is installed :) Well, in that case,
$PREFIX/share and $PREFIX/share/ede are your folders.
'dbus-1/services' folder contains unused file(s), but in future I will
probably add more service files. Also, one question: can you instruct
$PREFIX/share/xsession/ede.desktop to be placed in
/usr/share/xsessions/ede.desktop?
I never managed to force gdm to read any other folder than
/usr/share/xsessions. From this folder are read desktops that will be
presented in gdm menu for user choice.
It will be up in day/two, unfortunately; I'm just having conversation
with hosting company; HDD died a couple of minutes ago and they are
restoring data… The site, wiki, everything is down temporarily.
> I can excute most programs that come with EDE (like e.g. ede-about)
> but starting the panel does not work. This is what gets printed to
> the console:
Hm… AFAIK all panel applets are compiled with -fPIC support. Which
gcc version are you using? 64bit or 32bit? Can you paste me output
while ede-panel was compiled (just go in ede-panel folder and
run 'jam -dx')?
> Just wanted to try it, but I no longer get this error. Instead my
> browser keeps on loading - I guess, you're currently working on it
> so I'll try again later. Thanks for taking care of this so quickly!
We will try to resolve this when server is up again, so I can try to
reproduce your issue.
> However thanks to SF I still can't post a link to my blog… Perhaps
> if don't mention it directly? I'll try: The adress to the blog is
> "eerielinux DOT wordpress DOT com". The currently topmost post (#21)
> is the correct one. You'll find a download link there as well as the
> md5sum of the iso, the password for the login and some more
> information like that.
Got it. Good blog, btw!
I'm not sure, but can you post links without 'http://' part? I'm not
having problems with posting links; maybe because of different
privileges… Can you post links via forum markup?
Regards,
Sanel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Also, one question: can you instruct
$PREFIX/share/xsession/ede.desktop to be placed in
/usr/share/xsessions/ede.desktop?
I've just checked: It's right there in this dir in both the latest i686 and x86_64 packages. So these should be good to go for the repo.
I'm just having conversation
with hosting company; HDD died a couple of minutes ago and they are
restoring data… The site, wiki, everything is down temporarily.
Ugh. But good that you wrote it here, I was trying to access the bug tracker and the whole site was down! I'm glad that everything's back up again.
Hm… AFAIK all panel applets are compiled with -fPIC support. Which
gcc version are you using? 64bit or 32bit? Can you paste me output
while ede-panel was compiled (just go in ede-panel folder and
run 'jam -dx')?
I could paste it here (already redirected the output to a log file), but I guess that it may not be necessary anymore. I've updated to the newest version of Alpine and this one will no longer build the package. It fails with "error: TEXTRELS found!" and lists the shared objects that should go into usr/share/ede/panel-applets. Obviously Alpine doesn't like those.
At first I had no idea what a "TEXTREL" is and there seems not to be too much helpful material on that topic out there (or at least not any that somebody without coding skills could really benefit from). But I think I've got it now. Anyways I read somewhere that there had been problems with such relocating stuff and SELinux in the past and that textrels could be a potential security risk. Then I remembered that Alpine is meant as a very secure distro and that it's using a PaX patched kernel. As far as I understood both things, PaX's "randomly arranging of program memory" could be the problem here, right? If that's the case, I guess this is where portability ends and EDE will simply not run on that distro… :(
We will try to resolve this when server is up again, so I can try to
reproduce your issue.
You don't have to: It seems to be all working nicely now. I've also tried out the bug-reporter you mentioned and reported my first bug with it. Other things I wanted to report (like the negative values for SWAP in the display are already in the database). The only thing I didn't find there is the ede-config thing that was already mentioned here on the forums. I guess, I'll report it again just to make sure it's not forgotten. ;)
Got it. Good blog, btw!
Thanks a lot! Currently it's just mentioning EDE alongside other DEs but somewhen in the future, when I really start work on ELDER (the experimental ede-based distro) it will surely be tied to it a lot closer.
I'm not sure, but can you post links without 'http://' part? I'm not
having problems with posting links; maybe because of different
privileges…
I had tried that, but it also didn't work. Links in general work fine but if I refer to any wordpress blog (wanted to link to another one, too), SF won't let me post since that is detected as "spam". I guess this is to make aggressive advertizing of blogs impossible. But since I didn't want to do that but instead refer to a particular blog entry, it's a bit annoying.
BTW, I have a few questions for you.
1) On the wiki page that I edited (could you please give me feedback on that sometime? Just if what I did is ok for you since in that case I could go on improving the wiki) you asked the users not to just nag about what EDE is but instead come up with ideas on how to improve things. Now how to tell you about them? Many other projects use the bug tracker for that, too, introducing another category like "feature request" or something. Which way do you propose? Posing a "bug report" with a feature request, posting it here on the forums or writing you an email?
2) I know that anybody hates it, but I simply have to ask about future EDE versions - or more precise: the next one. You've made an edelib branch 2.0.1 which includes the icon fix. What is your plan in general? Do you want the next version to be a major release (e.g. 2.1) with new features and stuff or do you intent to release a minor version that focuses on fixing bugs and adding a few smaller things?
3) To me it seems like many interesting things are hardcoded at the moment. Any intentions to change this somewhere in the future? I'm for example stuck with a screen size of no more than 1024x768 on the computer I use EDE on. That does not leave much space for programs in the panel. I tried to "optimize" things by reconfiguring PekWM to only allow two instead of four workspaces and thus getting a little more space available. (Do we have an "EDE tips 'n tricks" page on the wiki yet? I guess stuff like that would fit in there!) I'd like to configure the clock so that it doesn't display seconds, I'd like to kick the CPU-meter (it's nice, but if I can trade it for some more space, I'd do so right away!) and above all I'd like to remove the field next to the EDE-button since I rarely use it and it wastes A LOT of space!
4) I've read through the documentation and found several grammar mistakes. What would be the best way to get them fixed? On my system I've also edited the desktop files so that they contain a translation string for my native language. I'm fine with an English system but a localized one just feels more "like home" and using EDE should feel good, right?
5) Just shortly FLTK 1.3.1 has been released. The new packages I uploaded are already built against it. Do you have plans to drop support for extremely old (five years??) FLTK versions in the next version(s)? I don't know if that what was added in the later versions would be of any use, but don't you think that a requirement of at least 1.10 would be sensible? Are there really any reasons NOT to upgrade to this particular version and stick with an earlier one?
Anyways… I've got to say it once again: Thanks for your work on EDE! I'm having it on my old laptop for just a few weeks now and I'm already feeling like it's been on there right from the beginning (in 2003…). I'm no longer missing LXDE and simply don't want anything else on there anymore. Together with the right progams, it just feels great to have such a light-weight DE working on a machine that old and surprising anybody that it's still working and running the latest webbrowsers, etc. Great work!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, karijes!
First: Thanks A LOT for all the efforts you put into Equinox and especially for keeping the project alive even when it was abandoned by the others!
I've added Equinox the the Arch Linux wiki just a few days before since it really mentioned most DEs with just EDE missing. You can have a look at it here, if you want: https://wiki.archlinux.org/index.php/Equinox_Desktop_Environment. In case there's anything wrong or missing, just tell me and I'll correct or add it.
BTW: I have no idea if you know it (who can keep track of all distros out there?), but on Arch EDE2 is available from the "Arch User Repository" which means that installing EDE is as easy as downloading two PKGBUILD files (edelib and ede), issuing the "makepkg" command and then install the packages. This is surely the next best thing to having pre-compiled binary packages available and certainly better than nothing (especially since even huge distros like Debian know nothing of Equinox!).
In my free time I sometimes like tinkering with older computers and while I also feel rather confortable with a console system or X + some WM, setting up a very frugal DE to get a "real desktop system" is a very nice challenge.
I've been using Linux (again) for some years now and finally kind of feel at home. However there's of course always some things which a user dislikes. Fortunately on Linux we can change things if we don't like them - and if we know how to do it. I had the idea of "starting a new distribution" (for learning purposes!) for quite a while as I feel that you learn the most if you actually do something. Having not too much inside knowledge of Linux and above all being no coder ( :( ), I hesitated to do it. But this is where Equinox came in!
While I can't remember when I found out EDE existed, I remember well that I thought it was dead due to the long time 2.0 remained beta and there was no development visible for me. "What a pitty!" I thought. It's not hard to guess how much I was surprised in May when I read on a German Linux news site that EDE 2.0 final had been released! At first I had a lot of trouble getting it to work (I failed on Gentoo and some other distros) and when I finally had EDE start on one box, the configuration didn't work. Yet I was and still am impressed by this DE - and by the fact that it's based on FLTK!
I think that LXDE for example is not a bad DE at all - but GTK+ is just way too fat if you ask me (not to even talk about Qt). I wondered if a GTK+-less and qt-less **desktop system could be built. Equinox answered the question: Yes - at least in theory. There are not too many FLTK programs available and the "FLTK Apps" project seems to go nowhere. In June I decided to just start my project. The primary goal is to learn a little more about the depths of GNU/Linux and the long-term goal to develop a "light-weight desktop distribution". The first one can't possibly fail and if the second goal is never achieved - well, it's ok, too.
Now I wonder what you as the developer of Equinox think about it: Some kind of test distro that tries to do without GTK+ and Qt and using EDE2 as its standard DE. Do you think there would be people interested in such a thing? The biggest problem would likely be standard applications. However I found that TinyCore have developed two FLTK-based file managers for example. Together with programs like MuPDF which don't require any toolkit at all, it *might* be possible to put together something like a FLTK/EDE2 desktop distribution! Of course many people will prefer Firefox or at least Midori over Dillo - but that's another story and far beyond the scope of this effort.
Anyway: Great work with EDE2! Please keep on improving it - it is very much appreciated.**
Hi,
Thank you for positive feedback! And thank you for filling Arch wiki
about EDE.
> I have no idea if you know it (who can keep track of all distros out
> there?), but on Arch EDE2 is available from the "Arch User
> Repository" which means that installing EDE is as easy as
> downloading two PKGBUILD
Didn't know this. Thanks for posting it. Can you write a little howto
for Arch, so I (or you if you find some time) can put it on wiki?
> I remember well that I thought it was dead due to the long time
> 2.0 remained beta and there was no development visible for me.
True, 2.0 development had it's problems, but now the things should go
smoother. This almost always happens when you are doing rewrite from
the scratch :D
> the configuration didn't work
Yes, I'm aware of this. However, I'm hoping configuration will be make
easier (and documentable) for 2.1 or 2.2 release.
> Now I wonder what you as the developer of Equinox think about it:
> Some kind of test distro that tries to do without GTK+ and Qt and
> using EDE2 as its standard DE. Do you think there would be people
> interested in such a thing?
Sure! For example, Minix community is a big 'no bloat' fan and Qt/Gtk+
aren't even in standard distribution. That is why I'm trying these
days to revive Minix port because previous EDE versions were quite
popular on it.
Also distros like TinyCore and Puppy are always welcoming something
done with FLTK. Since Minix, TinyCore or Puppy are still alive, tells
you enough how people are using it :D
I'm aware how file manager is, for now, big obstacle; one of previous
EDE developers started file manager project, but it isn't completed.
Maybe I revive it at some point, but my main priority for now is to
improve EDE portability and translation support.
For now, I will for sure recommend Fluff (TinyCore file manager);
AFAIK it is still actively developed.
> Of course many people will prefer Firefox or at least Midori over
> Dillo - but that's another story and far beyond the scope of this
> effort.
True; IMHO the main Dillo drawback (at least for me) is missing any
kind of javascript support: modern web pages are often unusable
without it and even basic javascript interpreter with mediocre speed
could improve the situation. Other than that, I'm considering Dillo
much superior than any browser out there ;)
Let me know about your progress.
Regards,
Sanel
Hi, Sanel!
Thanks for the quick answer!
Sure! I'm going to write one tomorrow.
Oh, something else: i686-binary packages for Arch Linux are just ~410 KB (edelib) and ~12 MB (ede) in size. I don't know what the hosting conditions of http://equinox-project.org/ are, but maybe even a custom repository could be set up. This would mean that an Arch user who wants to test EDE2 only had to add two lines to the .conf of his package manager and can simply install the DE afterwards just like any other package. If you're interested in it, I can also try to build x86_64-packages and look into how custom repos work (haven't been using Arch for long). That way anybody could give EDE a try without having to compile anything. I'd also volunteer to try and build updated packages if you release a new version (at least for the forseeable future).
That's great! Another important plus for EDE. I had previously tried to build a package for Alpine Linux. Right, usually nobody knows this, but I think that it's an interesting distribution (meant for embedded systems) being based on Busybox and µclibc instead of glibc. They managed to have Xfce (!!) run with ~40 MB of ram! Interested in just how small it gets, I wanted to try EDE, but while I was able to build binary packages for FLTK, ftjam (the distro does not come with too many packages available) and edelib, I wasn't able to solve my problems with the ede package. If I remember correctly, it was pekwm which didn't want to compile (or be linked). I dismissed this experiment, since µclibc is probably a very special case… But since you write that you are interested in portability (and EDE is well fit for embedded hardware) - are you interested in getting EDE to run on such a system, too? If so, I'd try to repeat my testing as time permits and post the error messages here.
In terms of translation I can also offer a little help: I can do (some) proofreading of English texts and can translate things to German if needed.
Yes, Fluff is probably the best choice for an FLTK fm. I know it from TinyCore, but I have not been able to get it to compile on Arch, yet. I'll have to take a look at that again sometime.
I totally agree: Dillo is fantastic for what it is. Problems are really the missing js support and the very bad html style that can be found just about everywhere on the net… But the Dillo developers already got pretty far with their browser. I'm quite positive that it will continue to improve, making it a real alternative.
I will. On Monday I'll post a link to my blog with the desktop test results (I compared ~20 Linux desktops, of course including EDE2).
> Oh, something else: i686-binary packages for Arch Linux are just ~410
> KB (edelib) and ~12 MB (ede) in size. I don't know what the hosting
> conditions of http://equinox-project.org/ are, but maybe even a custom
> repository could be set up.
I can arrange something. The hosting space is precious as hosting is
donated, but if you decide to continuously maintain the packages, we
could make mixed repo for Arch/Fedora/… on a single place.
> build a package for Alpine Linux. Right, usually nobody knows this,
> but I think that it's an interesting distribution (meant for
> embedded systems) being based on Busybox and µclibc instead of
> …
> I was able to build binary packages for FLTK, ftjam (the distro does
> not come with too many packages available) and edelib, I wasn't able
> to solve my problems with the ede package. If I remember correctly,
> it was pekwm which didn't want to compile (or be linked).
> …
> are you interested in
> getting EDE to run on such a system, too? If so, I'd try to repeat
> my testing as time permits and post the error messages here.
Absolutely! Can you please try it again and post pekwm errors here? I
always wanted to check how uclibc (and others minimal libc versions)
will work with EDE :)
> In terms of translation I can also offer a little help: I can do
> (some) proofreading of English texts and can translate things to
> German if needed.
Sure! Wiki already have support for browser specific languages, so
people for which German is native will automatically get German texts.
> I will. On Monday I'll post a link to my blog with the desktop test
> results (I compared ~20 Linux desktops, of course including EDE2).
Please drop me a link when you do so.
Regards,
Sanel
Hi, Sanel!
Are there Fedora packages, yet, or would Arch be the first Distro with EDE2 in a repo? Whatever the case, I guess you mean the way e.g. MATE does it (http://repo.mate-desktop.org/)? I think having a central place where packages for the various distros are kept is a good thing. Is there any other packaging currently going on? If I remember correctly, somebody attempted to bring EDE packages to Debian but has not succeeded so far. Right?
Building a custom repo was even easier than I thought. Here's a tarball with two Arch repos (i686 and x86_64 versions of edelib and EDE2): http://uploaded.net/file/5m69wpx1 I built edelib-2.0.1 for the repo, so it includes the icon fix you published here on the forums.
Depending on where you upload it, installing EDE on arch would mean adding something like the following two lines to the pacman.conf file and then just installing package ede regularly:
Server = http://equinox-project.org/repos/archrepo/$arch
This is just a suggestion. If you like e.g. like "" better, things can of course be called differently. Because of the packaging I did not yet write a howto, since if there are binary packages available, it's a completely different situation.
I have another question/suggestion here. Is there a reason that EDE2 consists of only two packages? I would prefer for example if pekWM was seperated and other WMs could be installed alongside EDE2 (and if it was only for testing purposes). But even more important: There's quite a lot of stuff (like all the PNG files) in the EDE package which doesn't really belong there; from the point of view of a packager, it would make sense to take these out of ede2-*-i686* and ede2-*-x86_64* where they mean double ballast and instead stuff them into something like an ede-common2-*any*. What do you think about moving any platform-independant files into an extra package which will be shared on all systems? I guess that this might also be a lot closer to the packaging guidelines of many distros. At least they frequently do this.
Ha, great! I just thought that I shouldn't be wasting your time with something like that - but I see we have a common interest in… unusual stuff. I'll definitely let you know when I got there again.
I'd love to, but SF won't let me. Whenever I try to post a reply that contains the name of the blog, it rejects it as "spam". I'm sorry that things are so cumbersome - but the blog's called "Eerie Linux" and is hosted on Wordpress. Please go there yourself and click on the "Overview of posts" link on the right side. It's blog entries 13. and 14. that deal with EDE.
Another testing series is planned for the future: I'll try to compare the amount of memory needed while doing a range of common tasks (browsing the web with 3 tabs, viewing a pdf, etc.) and I have a feeling that EDE + FLTK-Apps will easily win - IF I manage to find FLTK-based tools for every job (and get them to run).
I'll keep posting here when I have something about EDE (like an Arch-based live-CD which I also plan to create once I get some FLTK tools running).
Thank you for posting. I'll try to setup it in upcoming days and let you when is done :)
> Is there a reason that EDE2 consists of only two packages?
Agree, things like images and icons could be in separate package. However, the main idea
is to have as less packages as possible; it is much easier, especially for novice users. On other
hand, distros can repackage installed programs and stuff as they like.
But, if this proves to be unsuitable in future, I'll try to split them for sure.
Btw. I checked your blog posts; good work and read! And thank you for positive feedback :)
> I'll keep posting here when I have something about EDE
Of course. Always glad to hear that.
Regards,
Sanel
Hi, Sanel!
Great to hear that you'll set up the repo! I'll happily test it once it's ready.
That's true of course. Packaging uses fakeroot and "make install" (or "jam install" in our case) to build the package. However I can also copy the needed files manually, this is no problem. Which directories and/or files do you think should be stuffed into the ede-common package? Both packages will compile the whole thing that is in the ede-2.0-tar.gz source package, I guess, but I don't really mind that. For the actual ede package, I'd then just remove the files that are already in the common package from fakeroot folders and add ede-common to the new package's dependencies.
Well, and perhaps the WM could also be separated from the main package. Right now it's conflicting with the pekwm package that's available separately. I'd prefer control over simplicity. Also if we have a repo, it doesn't make a difference for the end-user if two packages are installed or four - more on the contrary actually: If somebody has pekwm already installed, ede will refuse to install as it is currently! If the wm was separate, that case would no longer be a problem.
I also found some time to install a fresh Alpine Linux today and build packages for fltk, ftjam and edelib. These are working well. Just as I wrote before, building the ede package fails because pekwm can't get linked. To get a bit closer to the problem, I tried if pure pekwm could be built, but it also fails.
I tested pekwm version 0.1.15 with makedepends "jpeg-dev, libpng-dev, libiconv-dev, libx11-dev" and no configure options except for setting the prefix.
The last lines of output are the following:
And if I try to build ede with makedeps "fltk ftjam autoconf automake dbus-dev libx11-dev jpeg-dev libpng-dev zlib-dev libxext-dev libiconv-dev" and no configure options except setting the prefix, these are the lines I think may be relevant:
Hopefully this helps in finding the problem. If not I can of course provide more information.
Hi, Sanel!
How are things going? I don't know if you're just very busy or if you missed my last post (with the packaging attempt on that µclibc-based distro).
Anyways, in the meantime I thought that I might well try something different and take a look at writing Gentoo ebuilds. I wrote one for edelib and got quite far with that. It downloads all the dependencies, builds the configure script, runs it and compiles edelib. Only the last step, packaging itself, fails.
The problem here is that jam DESTDIR="${path}" install works well for all files - except the docs. Everything gets installed to /var/tmp/portage/x11-libs/edelib-2.0.r-0/image//usr/bin/ (i.e. the fake-root, I think). Only for the docs, jam wants to create /usr/share/doc/edelib-2.0.0 and copy README, INSTALL and so on there. Portage prevents this and fails with an access violation.
I've taken a look at the Jamrules file for example and found where EDELIB_DOCDIR is set. I changed that in the ebuild with sed, but unfortunately this is really just the name of the doc dir and won't let me change the absolute path. I'm at my wits' end here, especially since I don't know how jam (or even makefiles) really work.
Do you have any idea why the documentation behaves so differently in comparison with the rest of the files? If we could fix this together, I'd try to create an ede2.0 ebuild as well. And if everything works, I can look into building a portage overlay from it so that Gentoo would be another platform to easily use EDE on. Of course I can write a short tut afterwards.
BTW: What's the Arch repo thing doing? I wanted to write a tutorial on that, too, once it's available.
Hi,
Thank you for pinging me. True, I was quite busy last two weeks and I'm restarting development again. I'll check what needs to be done and let you know when is completed (hopefully today).
Regards,
Sanel
Hi,
Finally got some time to do the work :) Arch repo is on; I put it on http://equinox-project.org/repos/archr/$arch
Related to that pekwm issue, have you have iconv installed? Looks like I'll have to put it as optional, since glibc is providing builtin iconv implementation.
> The problem here is that jam DESTDIR="${path}" install works well for all files
Did you used 'jam DESTDIR=<path>'? You have to use it as:
jam -sDESTDIR=<path>
with '-s' option, so jam can recognize it as variable. Works?
Regards,
Sanel
Hi, Sanel!
Thanks for putting up the Arch repo! I wanted to try it out, but pacman told me that it couldn't receive the db file. And if I try to access e.g. http://equinox-project.org/repos/archr/x86_64 in my browser, I get a 404. Same goes for its parent folder, http://equinox-project.org/repos/archr/. Perhaps a typo? http://equinox-project.org/repos/ does exist, though, but is inaccessable (403). Is there any reason not to permit browsing it?
Yes, I installed a seperate package "iconv" but it seems not to provide the expected function. Hm. If I remember correctly, Alpine tries to keep things slim and configuring programs not to build all optional features. I might try to remove the "iconv" package and compile one myself on my test system - perhaps that'll do. If not… Well. I'll post again. ;)
Unfortunately: No. It doesn't seem to make any difference. Like before, jam puts everything in the right directories except for the docs. It still wants to create a directory in /usr/share for them…
But I've also got some other news: I registered on EDE's wiki system today. I'm not really getting along well with it, yet (I'm used to the default, full-blown MediaWiki) but I've edited the FAQ page (just a few corrections). Would be nice if you find the time compare it with the latest revision before the changes and tell me wether you like it. If you do, I can offer some proofreading.
Hi,
True, it was a typo :) Here is the fixed link: http://equinox-project.org/repos/arch
Which jam version you have? Just hit the commands:
jam -sDESTDIR=/tmp/portage/x11-libs/edelib-2.0.r-0/image/ install
and got /tmp/portage/x11-libs/edelib-2.0.r-0/image/usr/share/doc/edelib-2.1.0 folder with the content. You can check jam version with 'jam -v'.
Regards,
Sanel
Hi, Sanel!
Yesss! It's working! I just tested both 32-bit and 64-bit on new Arch VMs. So at least on Arch installing EDE2 does no longer involve any compiling. A nice step ahead! :)
I'm going to post it on the Arch forums and ask for feedback there. If all goes well, I'll add it to the wikis and afterwards you can perhaps write a newspost for it? The latest one is rather old by now and for the reader it would certainly give a better impression if "there's something going on" with the project.
It tells me:
Sure. I'll be glad to post it when you are ready :)
Also I created issue regarding to jam. at http://bugs.equinox-project.org/show_bug.cgi?id=199 Can you try one small hack? I downloaded FTJam 2.5.2 and applied this hack, so installing docs worked.
Please add on the bottom of edelib-src/Jamrules the following code:
actions quietly MkDir1 {
mkdir -p $(<) ;
}
(please note the space before ';' as it is part of jam syntax. Now can you please remove /tmp/portage folder and recompile and install it again? Works?
Regards,
Sanel
Hi, Sanel!
Arrg! "Sorry, the text entered looks like spam and cannot be posted." Again! I have no idea how to get along with that properly… I'll try to post it without the ebuild and abuild files.
For Gentoo: I don't know whether it's a typo again, but Gentoo uses FTJam 2.5.3(-rc2). I tried adding your three lines using echo and sed, but - again - it unfortunately doesn't make a difference.
I've read your bug tracker entry and I don't think that it's a general FTJam issue but rather a Gentoo specific (?) one. On both Arch and Alpine FTJam is used to build edelib and ede and there seems to be no problems (the "-s" option is missing on the Arch PKGBUILD, btw.). For that reason I took a look at Gentoo's FTJam ebuild - it seems apply several patches.
Perhaps this can give you any clue? Here's the content of the file ftjam-2.5.3_rc2-r1.ebuild:
BTW: With the version haiku-jam that you offer here on SF, packaging works well! I downloaded and compiled it on my Gentoo test system, copied the jam executable into the source dir and changed the jam command in the ebuild to ./jam. That installs the docs to the right place and the edelib installs correctly. If all else fails, this could be a last resort way to get things done.
Alpine: I've taken a look at the iconv ABUILD and what I expected is not the case. But I'll post the content of the APKBUILD, anyway:
Arch: Over 170 people have clicked the thread that I created, but so far nobody has posted anything about the packages. Let's see if that changes in the next few days.
Other things: I've build another testing VM with Arch and FLTK1.1.10. Edelib and EDE work well and thanks to a friend of mine I could get Fluff to compile with that version. Same goes for some other FLTK applications that would be nice/important to have for the experimental distro. However Dillo needs FLTK1.3 and is of course completely indispensable. :(
With Fluff being still in development, I think chances are that it'll eventually get ported over (probably not before TinyCore switches to FLTK1.3, though). For most of the other projects that'll most likely not be the case. What do you think about installing both FLTK versions on the same system? Like 1.3.0 installing normally and 1.1.10 into /usr/lib/fltk11 or anything like that? A stopgap for sure, but perhaps an option to get things started at all.
And here are the buildfiles as an xz archive uploaded seperately: http://www.file-upload.net/download-6745121/buildfiles.tar.xz.html
Hi,
Sorry for late reply; I was on trip back home from conference…
> Perhaps this can give you any clue? Here's the content of the file
> ftjam-2.5.3_rc2-r1.ebuild:
Hm… how about filling a ticket to gentoo devs? If all jam versions
(stock, ftjam and haiku) are working, except that version with
patches, probably those patches are making some issue?
> Arch: Over 170 people have clicked the thread that I created, but so
> far nobody has posted anything about the packages. Let's see if that
> changes in the next few days.
Nice!! Maybe they didn't find any issues installing it :D
> What do you think about installing both FLTK versions on the same
> system? Like 1.3.0 installing normally and 1.1.10 into
> /usr/lib/fltk11 or anything like that? A stopgap for sure, but
> perhaps an option to get things started at all.
Sure, this can work. I have the same setup, where I keep 1.3.0 in
/usr/local and 1.1.10 in /opt/fltk11. Just make sure Fluff catch
fltk-config in /opt/fltk11 before the one in system folder. You can
do this by exporting PATH variable like:
export PATH="/opt/fltk11/bin:$PATH"
Or, Fluff maybe have option to manually specify fltk-config path.
PS: what you would like me to do with those buildfiles; replace them in arch repo?
Regards,
Sanel
Hi, Sanel!
You're right, I'm going to ask in the forums once I find the time for it. Maybe someone will care!
The only thing I think should be corrected with the packages in repo is that EDE was "compiled without XKB extension". I guess that this is due to myself compiling them on a bare system which had no packages installed but those that were real dependencies. Could you tell me please which packages should be added to the deps so that EDE is fully functional (without the very useful feature to change keyboard layout easily, it's crippled unnecessarily)?
Oh, and would you also tell me which files from the EDE source package you think could be packed into a new binary package ede-common? Since I have to rebuild the packages again before the announcement anyway, I might as well do things right from the start. I took a little time to skim-read some of the packaging documentation for DEB and RPM packages. The packaging guidelines are quite strict and the whole thing is rather complex. But if anybody ever wants to provide packages for systems like Debian or SuSE, we really should split things. At least for official packages it's even a requirement and for unofficial ones probably still "bad style" if we don't.
(I can't promise anything, but I might dig a little deeper into packaging on various distros to make EDE a little easier to access and hopefully better known.)
Thanks for the tip! I'll mess with it a little - and who knows, perhaps something usable will come out.
No, these are the build files for FTJam on Gentoo and for Iconv on Alpine. In the FTJam one you can see what patches are applied - but you're right. This issue is not actually your problem and I'll ask the Gentoo guys.
On the µclibc-based distro I'm not getting EDE (or Pekwm) compiled and it does not seem that the iconv package was crippled in any way. The build file should give you an idea which version is used on Alpine and if the particular version is fit for the routines needed by Pekwm.
Hi,
> The only thing I think should be corrected with the packages in repo
> is that EDE was "compiled without XKB extension". I guess that this
> is due to myself compiling them on a bare system which had no
> packages installed but those that were real dependencies. Could you
> tell me please which packages should be added to the deps so that
> EDE is fully functional (without the very useful feature to change
> keyboard layout easily, it's crippled unnecessarily)?
Aaah yes, I almost always forgot about this extension… You will need
libxkbfile (and libxkbfile-devel if distro split development and
ordinary libraries). AFAIK, beside X packages, you will need mentioned
XKBfile and XShape extensions, libxpm and curl. The rest is mentioned
on wiki (hoping I didn't forgot anything else).
> Oh, and would you also tell me which files from the EDE source
> package you think could be packed into a new binary package
> ede-common?
Sure. I would put ede.desktop, icon-themes, menu, mime-types, pekwm
and wallpapers found in 'data' folder. Be aware how 'ede.desktop' must
go in session manager folder (usually in /usr/share/xsession), no
matter where ede was installed. This depends on used session manager
and it's configuration, but I always put in mentioned folder.
> But if anybody ever wants to provide packages for systems like
> Debian or SuSE, we really should split things. At least for
> official packages it's even a requirement and for unofficial ones
> probably still "bad style" if we don't.
Yes, I know how they keep things a bit complex and big 'Thank You!' for
investigating this field :)
> On the µclibc-based distro I'm not getting EDE (or Pekwm) compiled
> and it does not seem that the iconv package was crippled in any
> way. The build file should give you an idea which version is used on
> Alpine and if the particular version is fit for the routines needed
> by Pekwm.
Hm… can you add '-liconv' option to pekwm Jamfile; just scroll to
the bottom of pekwm/Jamfile and modify line:
LinkAgainst pekwm : $(PEKWM_LIBS) $(STDLIB) ;
to
LinkAgainst pekwm : $(PEKWM_LIBS) -liconv $(STDLIB) ;
and try again. If iconv is located in different folder than /usr/lib
(you can check it with 'ls -la /usr/lib/libiconv*'), like
'/usr/local/lib', just modify above line to:
LinkAgainst pekwm : $(PEKWM_LIBS) -L/usr/local/lib -liconv $(STDLIB) ;
You can apply the same for other folders.
This iconv thing is probably the major issue with pekwm because it
is quite unportable among OS-es, even if it was designed
otherwise. I'll try to address it in next versions, but for now it
must be present to allow proper utf8 conversion.
Let me know what gentoo crew replied :)
Regards,
Sanel
Hi, Sanel!
With XShape you mean Xext? I've built new Arch packages on sunday but have not included that one as a dep. Had issues with invisible mouse cursor, too, so I'll have to take a closer look when I come home tomorrow.
Beside that, I've split the packages like this: edelib is untouched (or should I add some optional deps there, too?). Ede now only contains everything that goes into /usr/bin and the shared objects in /usr/share/ede/panel-applets. Then I made a ede-data as you suggested (do you like 'data' more than 'common'? I think both are in use out there) and put the rest of dirs in there, except for the wallpapers that are seperately put into ede-wallpapers.
Package ede depends on both edelib and ede-data now and has an optional dependency on ede-wallpapers which is suggested for installation but not needed. While I like the wallpapers (especially the winter night one) they are pretty high-res and rather big. All EDE packages together are still ~12.3 MB in size but leaving out the optional wallpapers, the size is cut down to 5.2 MB! I wish I had known this eariler (for the results of the DE tests on my blog)! ;)
I also renamed the repo database to , since there seems to be more software that goes by the name "equinox". What do you think about these suggestions? If you're happy with them, I'll try to get the new packages built and uploaded tomorrow evening.
You're welcome! I said that I wanted to help and since I'm limited to non-coding tasks, this is probably something that I can actually do.
That sounded reasonable, I had to try it right away. Result: Success! I also added -lXext to ede-desktop and building the package works with no more errors now! Thanks for the tip!
However the machine I built this on is not capable of running X today (some ancient VIA graphics chip that makes unichrome crash with segmentation fault and xf86-vesa also not working for whatever reason) even though it has worked in the past (SuSE 7.0 around the year 2000). So I can't test EDE right now, but I'll tell you as soon as I can. I'm VERY curious how little RAM will be needed! :)
BTW: A friend visited me last weekend and I showed him FLTK. He didn't know it before but liked it. Result of a little playing around: I have a working Fluff package for Arch now that works with FLTK 1.3 and has a TinyCore specific feature removed. He also got some more FLTK apps working that I was having trouble with. I think I'll have a first "alpha-preview" of what gave this forum thread its name working soon. I'll let you know.
Oh, and another thing: Since I've been actually using EDE on my old laptop, I've found a few bugs that I wanted to report. To see if they were already known, I registered on the bug tracker but I can't use it. Currently I only have Chromium available for browsing and whenever I click on either ede or edelib and then select "general", I get a 404 ("The requested URL /bugzilla/bugzilla/buglist.cgi was not found on this server."). Is it only me or is there something wrong?
Of course, I will. However I thought that I might do a little more tinkering first. I'll edit the ftjam ebuild and disable the patches to see if it works then. Perhaps I can find out which patch (or which combination) breaks it. Being able to provide more information will increase chances to actually get this issue resolved, I guess. But even if it ends with a "won't fix", I'm pretty sure now that I'll come up with a more or less ugly workaround. I'm still determined to bring EDE to Gentoo, too! *g*
Hi, Sanel!
Like I wrote in my last post, I hope that Xext is what you suggested adding. I've solved the problem of the missing cursor by rebuilding edelib, too, with some of the deps added as well. I've build new packages (the way I described above) for both platforms and uploaded them. You can download the tarball here: http://www.file-upload.net/download-6821974/archrepo.tar.html
In case of the build on Alpine: While the package was successfully built, it does not work completely. When I start X, ede obviously launches pekwm but then I'm left with just the one color background and nothing more. I've added a terminal emulator to be started, too, so I can have a look at what happens.
I can excute most programs that come with EDE (like e.g. ede-about) but starting the panel does not work. This is what gets printed to the console:
Do you have any idea where to add this before building the package again?
About the bug tracker again: It seems to be seriously broken for some reason. The problem I encountered is not browser specific. I tried again with Firefox but whenever I log in, click "browse" and select any category (doesn't matter if it's 'ede', 'edelib', 'efltk' or 'www') the next page only offers me 'general' which leads to a 404 (/bugzilla/bugzilla/buglist.cgi not found). Probably it's a problem with the double directory ("/bugzilla/bugzilla")?
And one more news: I've released the first alpha version of a project that I call "Desktop Demo DVD". Its goal is to provide a live medium with a graphical login manager where a bunch of desktop environments (or better: All that I can get to run) can be selected and easily tested. This early version provides 5 DEs - among them, of course, EDE (the other ones being: MATE, Xfce, LXDE, Enlightenment 17).
I'm not sure yet what people think of it and if I should continue the project. But if it shows that there's interest in it, it could lead to people getting to know the less well-known DEs, too. In any case, EDE is in there right from the beginning.
Oh crap!!! I made reply on your post, but it disappeared #@#!!
Sourceforge from time to time eats these forum posts… If I don't
reply you in day-two, please mail me or post comment on my blog.
Sh*tty hosting…
> Like I wrote in my last post, I hope that Xext is what you suggested
> adding. I've solved the problem of the missing cursor by rebuilding
> edelib, too, with some of the deps added as well.
True, Xext is the extension.
I'll try to remember what I replied you for previous post…
> Then I made a ede-data as you suggested (do you like 'data' more
> than 'common'? I think both are in use out there) and put the rest
> of dirs in there, except for the wallpapers that are seperately put
> into ede-wallpapers.
Excellent; only I suggested you put content from 'data' folder in it,
and is fine to keep the name under ede-common, but if you like
'ede-data', fine with me ;)
> All EDE packages together are still ~12.3 MB in size but leaving
> out the optional wallpapers, the size is cut down to 5.2 MB! I wish
> I had known this eariler (for the results of the DE tests on my
> blog)! ;)
Good! True, wallpapers are space eaters as they are in high resolution.
> I also renamed the repo database to , since there seems
> to be more software that goes by the name "equinox". What d- you
> think about these suggestions? If you're happy with them, I'll try
> to get the new packages built and uploaded tomorrow evening.
Can it be named 'ede' please? This equinox name is often related to
eclipse project and 'ede' is a little bit less to type and easy to
remember.
> However the machine I built this on is not capable of running X
> today (some ancient VIA graphics chip that makes unichrome crash
> with segmentation fault and xf86-vesa also not working for whatever
> reason) even though it has worked in the past (SuSE 7.0 around the
> year 2000). So I can't test EDE right now, but I'll tell you as soon
> as I can. I'm VERY curious how little RAM will be needed! :)
Me too! Please let me know about the status so I can optimize things
here and there is is needed.
> have a working Fluff package for Arch now that works with FLTK 1.3
> and has a TinyCore specific feature removed. He also got some more
> FLTK apps working that I was having trouble with. I think I'll have
> a first "alpha-preview" of what gave this forum thread its name
> working soon. I'll let you know.
Excellent! Again, let me know about the progress :)
> the problem I encountered is not browser specific. I tried again with
> Firefox but whenever I log in, click "browse" an0 select any
> category (doesn't matter if it's 'ede', 'edelib', 'efltk' or 'www')
> the next page only offers me 'general' which leads to a 404
> (/bugzilla/bugzilla/buglist.cgi not found). Probably it's a problem
> with the double directory ("/bugzilla/bugzilla")?
Ahh, yes, it is the problem with our hosting; at the beginning we had
perfect bugzilla setup, but hosting got messed up with various
updates; just remove all 'bugzilla' parts in url and you will get it
working.
However, if you had curl installed when you compiled EDE, you can use
ede-bug-report tool, which will post issues automatically on
bugzilla. The downside is that you will not get updates when I comment
on issue, but I will contact you via mail is something is needed.
> And one more news: I've released the first alpha version of a
> project that I call "Desktop Demo DVD". Its goal is to provide a
> live medium with a graphical login manager where a bunch of desktop
> environments (or better: All that I can get to run) can be selected
> and easily tested. This early version provides 5 DEs - among them,
> of course, EDE (the other ones being: MATE, Xfce, LXDE,
> Enlightenment 17).
Congratulations. Can you send me a download link, so I can update
download page with it?
> I'm not sure yet what people think of it and if I
> should continue the project. But if it shows that there's interest
> in it, it could lead to people getting to know the less well-known
> DEs, too. In any case, EDE is in there right from the beginning.
Sure, there will be always interest from people to try something new,
but without hassle of installing, compiling and such stuff. We are
getting lazier every day :D
> I've build new packages (the way I described above) for both
> platforms and uploaded them. You can download the tarball here:
> http://www.file-upload.net/download-6821974/archrepo.tar.html
I'll update the repo.
Again, thanks for patience :)
Regards,
Sanel
Hi, Sanel!!
Thanks for posting again in this case! We all love SF, I guess… But good to know that it's ok for you to write again as a reminder or in case anything like this happened. I deliberately waited for a little over a week because I didn't want to get on your nerves. ;) So now I know better - and this may speed things up a little!
Ah, now I see. You mean the stuff that's in folder 'data' in the builddir… I didn't find any such folder when I examined what gets installed by "jam install", so I didn't quite understand. I changed the name to 'ede-common' again, since I feel this sounds more familiar somehow.
Yes, of course. That's why I asked you what name you'd prefer. ;)
I rebuilt all packages again including the name change from 'data' to 'common'. Also the repo's database files use the name 'ede' now so that the repo's name will be '' on Arch.
Please download the new tarball again from here: http://www.file-upload.net/download-6823546/archrepo_new.tar.html
Let me know when it's up; I'll test it one more time then and afterwards prepare a little tutorial for the wiki. :)
I can't figure out how to do away with the error message I quoted in the last post. Except for ede-panel everything seems to work (I checked some random executables). Can you tell me in which file I should add the recommended "-fPIC" option? Or is this perhaps not even the right way to solve the problem?
Just wanted to try it, but I no longer get this error. Instead my browser keeps on loading - I guess, you're currently working on it so I'll try again later. Thanks for taking care of this so quickly!
The problem was (or is) that I cannot browse the bugs already reported to know if it's a new issue that I should create a ticket for,
Hm. I'm not quite sure if it's worth being put on the EDE site. It's a really early version and hosted on a 1-click hoster. On the other hand I might reach a few more people that way and perhaps find somebody who's interested in helping… Well, I propose you take a look at it if you feel like it and then decide yourself. After all I released it to the public and everybody can do with it as he wants. *g*
However thanks to SF I still can't post a link to my blog… Perhaps if don't mention it directly? I'll try: The adress to the blog is "eerielinux DOT wordpress DOT com". The currently topmost post (#21) is the correct one. You'll find a download link there as well as the md5sum of the iso, the password for the login and some more information like that.
Next I intent to dedicate my time to Gentoo again (or perhaps Alpine if the problem I ran into is not a big one).
> You mean the stuff that's in folder 'data' in the builddir… I
> didn't find any such folder when I examined what gets installed by
> "jam install", so I didn't quite understand. I changed the name to
> 'ede-common' again, since I feel this sounds more familiar somehow.
Yes, in builddir, but I forgot that package will pick installed
folders, not those from where is installed :) Well, in that case,
$PREFIX/share and $PREFIX/share/ede are your folders.
'dbus-1/services' folder contains unused file(s), but in future I will
probably add more service files. Also, one question: can you instruct
$PREFIX/share/xsession/ede.desktop to be placed in
/usr/share/xsessions/ede.desktop?
I never managed to force gdm to read any other folder than
/usr/share/xsessions. From this folder are read desktops that will be
presented in gdm menu for user choice.
> Please download the new tarball again from here:
> http://www.file-upload.net/download-6823546/archrepo_new.tar.html
> Let me know when it's up; I'll test it one more time then and
> afterwards prepare a little tutorial for the wiki. :) ""
It will be up in day/two, unfortunately; I'm just having conversation
with hosting company; HDD died a couple of minutes ago and they are
restoring data… The site, wiki, everything is down temporarily.
> I can excute most programs that come with EDE (like e.g. ede-about)
> but starting the panel does not work. This is what gets printed to
> the console:
Hm… AFAIK all panel applets are compiled with -fPIC support. Which
gcc version are you using? 64bit or 32bit? Can you paste me output
while ede-panel was compiled (just go in ede-panel folder and
run 'jam -dx')?
> Just wanted to try it, but I no longer get this error. Instead my
> browser keeps on loading - I guess, you're currently working on it
> so I'll try again later. Thanks for taking care of this so quickly!
We will try to resolve this when server is up again, so I can try to
reproduce your issue.
> However thanks to SF I still can't post a link to my blog… Perhaps
> if don't mention it directly? I'll try: The adress to the blog is
> "eerielinux DOT wordpress DOT com". The currently topmost post (#21)
> is the correct one. You'll find a download link there as well as the
> md5sum of the iso, the password for the login and some more
> information like that.
Got it. Good blog, btw!
I'm not sure, but can you post links without 'http://' part? I'm not
having problems with posting links; maybe because of different
privileges… Can you post links via forum markup?
Regards,
Sanel
Hi, Sanel!
I've just checked: It's right there in this dir in both the latest i686 and x86_64 packages. So these should be good to go for the repo.
Ugh. But good that you wrote it here, I was trying to access the bug tracker and the whole site was down! I'm glad that everything's back up again.
I could paste it here (already redirected the output to a log file), but I guess that it may not be necessary anymore. I've updated to the newest version of Alpine and this one will no longer build the package. It fails with "error: TEXTRELS found!" and lists the shared objects that should go into usr/share/ede/panel-applets. Obviously Alpine doesn't like those.
At first I had no idea what a "TEXTREL" is and there seems not to be too much helpful material on that topic out there (or at least not any that somebody without coding skills could really benefit from). But I think I've got it now. Anyways I read somewhere that there had been problems with such relocating stuff and SELinux in the past and that textrels could be a potential security risk. Then I remembered that Alpine is meant as a very secure distro and that it's using a PaX patched kernel. As far as I understood both things, PaX's "randomly arranging of program memory" could be the problem here, right? If that's the case, I guess this is where portability ends and EDE will simply not run on that distro… :(
You don't have to: It seems to be all working nicely now. I've also tried out the bug-reporter you mentioned and reported my first bug with it. Other things I wanted to report (like the negative values for SWAP in the display are already in the database). The only thing I didn't find there is the ede-config thing that was already mentioned here on the forums. I guess, I'll report it again just to make sure it's not forgotten. ;)
Thanks a lot! Currently it's just mentioning EDE alongside other DEs but somewhen in the future, when I really start work on ELDER (the experimental ede-based distro) it will surely be tied to it a lot closer.
I had tried that, but it also didn't work. Links in general work fine but if I refer to any wordpress blog (wanted to link to another one, too), SF won't let me post since that is detected as "spam". I guess this is to make aggressive advertizing of blogs impossible. But since I didn't want to do that but instead refer to a particular blog entry, it's a bit annoying.
BTW, I have a few questions for you.
1) On the wiki page that I edited (could you please give me feedback on that sometime? Just if what I did is ok for you since in that case I could go on improving the wiki) you asked the users not to just nag about what EDE is but instead come up with ideas on how to improve things. Now how to tell you about them? Many other projects use the bug tracker for that, too, introducing another category like "feature request" or something. Which way do you propose? Posing a "bug report" with a feature request, posting it here on the forums or writing you an email?
2) I know that anybody hates it, but I simply have to ask about future EDE versions - or more precise: the next one. You've made an edelib branch 2.0.1 which includes the icon fix. What is your plan in general? Do you want the next version to be a major release (e.g. 2.1) with new features and stuff or do you intent to release a minor version that focuses on fixing bugs and adding a few smaller things?
3) To me it seems like many interesting things are hardcoded at the moment. Any intentions to change this somewhere in the future? I'm for example stuck with a screen size of no more than 1024x768 on the computer I use EDE on. That does not leave much space for programs in the panel. I tried to "optimize" things by reconfiguring PekWM to only allow two instead of four workspaces and thus getting a little more space available. (Do we have an "EDE tips 'n tricks" page on the wiki yet? I guess stuff like that would fit in there!) I'd like to configure the clock so that it doesn't display seconds, I'd like to kick the CPU-meter (it's nice, but if I can trade it for some more space, I'd do so right away!) and above all I'd like to remove the field next to the EDE-button since I rarely use it and it wastes A LOT of space!
4) I've read through the documentation and found several grammar mistakes. What would be the best way to get them fixed? On my system I've also edited the desktop files so that they contain a translation string for my native language. I'm fine with an English system but a localized one just feels more "like home" and using EDE should feel good, right?
5) Just shortly FLTK 1.3.1 has been released. The new packages I uploaded are already built against it. Do you have plans to drop support for extremely old (five years??) FLTK versions in the next version(s)? I don't know if that what was added in the later versions would be of any use, but don't you think that a requirement of at least 1.10 would be sensible? Are there really any reasons NOT to upgrade to this particular version and stick with an earlier one?
Anyways… I've got to say it once again: Thanks for your work on EDE! I'm having it on my old laptop for just a few weeks now and I'm already feeling like it's been on there right from the beginning (in 2003…). I'm no longer missing LXDE and simply don't want anything else on there anymore. Together with the right progams, it just feels great to have such a light-weight DE working on a machine that old and surprising anybody that it's still working and running the latest webbrowsers, etc. Great work!