MeeCoLay Development Thread [no "doesn't work" reports!!]
 

Hello,
I created this thread to keep dev discussion away from all the user stuff.

First of all we need to consider the structure of the libraries. tar.bz2 or a repo with debs?

User qwazix suggested a repository with libs and apps.

My arguments:

For:
1. Apt-get handles deps, auto-installs it: no mess with creating a client
2. Easy removing

Against:
1. You need to mess with the whole depends stuff, it requires much work. You need to add meecolay pkgs to pre-deps and there's a bit mess out there, it's still developed
2. Repo'll be removed after launching HAM, adding n' removing repo only install time, not to require additional root, will slow down any other repos update
3. Duplicate of apps, developers could use DEBIAN/meecolay instead to provide install instructions for meecolay.
4. essential libs if edited unproperly may brick the n900 (if u use shlibs or sth)

What do you think about it?

Re: MeeCoLay Development Thread [no "doesn't work" reports!!]
 

do you have any idea how to deal with libraries possibly overwriting core fremantle files? E.g. Harmattan package "SomePackageA" contains file "/lib/somelibrary.so" and Fremantle package "SomePackageB" contains file "/lib/somelibrary.so" (it would happen - or should happen - only when these are in fact same software, but in different version). Harmattan's version may, as we all well know, cause Fremantle device reboot loop. (I think you may have thought about it by your 4# point of "Against"). Maybe using something like Easy Debian's fake root environment, for installing Meego's libs, wouldn't be such a bad idea after all? What's more, it could be saved in MyDocs then, not polluting small /opt partiton. Anyway, I vote for repository solution instead of tar.gz solution ;)

Re: MeeCoLay Development Thread [no "doesn't work" reports!!]
 

The libraries just would have to be put in /opt/meecolay/lib, as it's now.

With Debian chroot's the best option as Debian packages ain't optified. With meego, core pkgs are non-opt and apps are opt. (/opt/packagename/bin, etc.)

Will chroot handle all the rotation stuff properly?? We'll need to find some kinda blacklisting.

With app allegro there's such problem. I blacklist
The app's executable is in /opt/allegro/bin/allegro.

this doesn't work. Is something more required to blacklist apps from rotating?

Re: MeeCoLay Development Thread [no "doesn't work" reports!!]
 

I have a nice idea, combining yours and mine,
The same that it is, but made debs!

What do you think about?

It would require a minor change in the src.

I'm nearly done finsihing the basic stuff in the client, some early build should arrive soon

Re: MeeCoLay Development Thread [no "doesn't work" reports!!]
 

I think I don't fully understand what you mean, could you clarify a bit? ;) If you have problems with explaining it in english, you may PM me in polish or german if you speak one of those languages better (I speak both) ;)

Re: MeeCoLay Development Thread [no "doesn't work" reports!!]
 

Instead of using .tar.bz2 and unpacking this, the .deb packages may be done and the downloader would call dpkg to install this.


But I noticed a problem now: this would require root access. As with meecolay-installer without root it would just generate new package, as you may want to use it later, there it's not nice to install all of this manually.

It's better to have this program rootless, as root may be ruthless :)

Seriously, when you fire up program using sudo as root, you'll get a sendmail help ;P

Re: MeeCoLay Development Thread [no "doesn't work" reports!!]
 

Hello
How does the CSSU check whether app should be rotated or not (in blacklist)?
I cannot blacklist it altough I give the executable's name.
it's not in /usr/bin or /bin

Re: MeeCoLay Development Thread [no "doesn't work" reports!!]
 

I have no idea. You could try xdotool to check window names, e.g. run when the app window is active... so run something like in terminal, then switch quickly to the other app and after few seconds check result in terminal. I have no idea if this will be the same window name that is used in hildon-desktop blacklist, but I can check later if you want (after all, I'm maintainer of xdotool for Fremantle, so I know source code a little bit... I never needed touse getwindowname though, so I', not sure if it's equal to XClassHint.res_name value...)

Edit: But the best way would be activating cssu source repo, then Then modify the file and function I gave you the reference to in the other thread, add there printing window name to some log file on every check, then
and installing resulting deb on device. That would take ~15-30 minutes I guess, if you don't have time, mayone someone else has time and will to help you (I would by I am extremely busy lately, so I cannot primise anything, sorry :( ).

Re: MeeCoLay Development Thread [no "doesn't work" reports!!]
 

The window name for app "allegro", executable "/opt/allegro/bin/allegro" is "allegro". But blacklisting "allegro" doesn't work.

What may be the problem?

Re: MeeCoLay Development Thread [no "doesn't work" reports!!]
 

I don't know, sorry :( I'm waiting for my second device (I will have two N900s :D), when it arrives, I will check window names with modified hildon-desktop and report back (it should happen this week).