Reply
Thread Tools
Posts: 915 | Thanked: 3,209 times | Joined on Jan 2011 @ Germany
#11
Originally Posted by sulu View Post
So I think the only problem might be the low resolution. This could be tested in a VM in advance. And even if it is a problem, there are ways around that if you're wiling to accept a degraded display quality.
I just tried, and although LXDE can in principle be usable at 480x288, most applications aren't.
But if you scale the desktop by divisor 2 (xrandr --scale 2x2), you get a desktop of 960x576, which is similar to netbooks and on the lower end of being usable.
The display won't be crisp anymore, but it should still be good enough in most situations.
 

The Following 3 Users Say Thank You to sulu For This Useful Post:
Posts: 1,203 | Thanked: 3,027 times | Joined on Dec 2010
#12
I'm not saying it would be super easy, but given what I have so far I think a h-d GTK3 port would be feasible and would probably be easier in the long run because of the amount of touch work that it is now integrated in upstream GTK (goodbye GTK2 maemo patches!). Its really at the point sometimes where you wonder if its worth keeping some of the Hildon classes/widgets.

HildonPannableArea for example should, as touch is integrated in GtkScrolledWindow, only need hildon_pannable_area_jump_to/scroll_to. It actually needs a little more because we can't directly tell it to animate to a certain point. All the toolbar edit/long press stuff can be simplified (or removed for now ) The smaller libhildon, the less we have to maintain in the long run. If libhildon used CSDs for the app menus instead of h-d you could potentially swap the window manager for anything.

I could be using profiled, mce, etc etc from cssu in my GTK3 work if only I knew how to RE one closed library (libsystemui IIRC). As it is I'm often relying on the Mer/Nemo counterparts/upstream versions and either using the existing Debian packaging rules or churning out my own set. The one problem with this is that then brings in statefs. It's a lovely idea, but Nemo/Sailfish are using Qt, so their solution for modules don't fit with GTK based desktop as nicely. Unfortunately there are a few points in the code for h-d where even attempting to build without mce etc still tries to use it. Fix these and you could theoretically use it as a desktop OS.

I can't say anything about battery life because I haven't tried any of it on a real device yet, only in amd64 Jessie vm.
 

The Following 4 Users Say Thank You to Android_808 For This Useful Post:
endsormeans's Avatar
Posts: 3,139 | Thanked: 8,156 times | Joined on Feb 2013 @ From my Gabriola Island hermitage, near the Edge of the World
#13
As far as desktop environments go...
I realize it has been a rough path getting enlightenment to run (but it is very configurable and slick looking)
Past "E"
My best suggestion is wmaker or wm2 for the flexibility of the minimal screen real estate on the n900.
wmaker worked quite well on the n8x0 and I enjoyed using it ...
I'm sure it would suffice for our needs on the n900.
It may not be "pretty" and polished ... but it is very very configurable and very functional for the purpose of the n900...without icons, fonts, etc disappearing on the n900.
I am sure there are other de possibles which would do as well.

As a side note.. obtusely... I have been very pleasantly surprised at the options in antix ...with the (now antiquated) options for de's... just don't find the cool stuff anymore preinstalled.
__________________
Lurker since 2007, Member since 2013, Certifiable since 1972

Owner of :
1-n770 (in retirement), 3-n800's / 3-n810's (still in daily use), 5-n900's ((3 are flawless, 1 loose usb ( parts), 1 has no telephony (parts))
3-nexus 5's : 1 w/ Floko Pie 9.1 (running beautifully) waiting for Stable Droid 10 rom, 1 w/ ̶Ubuntu Touch, 1 with Maru OS (intend maemo leste when ready)

1/2 - neo900 pre- "purchased" in 2013. N̶o̶w̶ ̶A̶w̶a̶i̶t̶i̶n̶g̶ ̶r̶e̶f̶u̶n̶d̶ ̶p̶r̶o̶c̶e̶s̶s̶ ̶l̶a̶s̶t̶ ̶f̶e̶w̶ ̶y̶e̶a̶r̶s̶ - neo900 start up declared officially dead -
Lost invested funds.


PIMP MY N8X0 (Idiot's Guide and a video walkthrough)http://talk.maemo.org/showthread.php?t=94294
THE LOST GRONMAYER CATALOGShttp://talk.maemo.org/showthread.php...ight=gronmayer
N8X0 VIDEO ENCODING THE EASY WAYhttp://talk.maemo.org/showthread.php...ght=mediacoder
242gb ON N800http://talk.maemo.org/showthread.php?t=90634
THE PAIN-FREE MAEMO DEVELOPMENT LIVE DISTRO-ISO FOR THE NOOB TO THE PROhttp://talk.maemo.org/showthread.php?t=95567
AFFORDABLE MASS PRODUCTION FOR MAEMO PARTShttp://talk.maemo.org/showthread.php?t=93325

Meateo balloons now available @ Dave999's Meateo Emporium
 

The Following 4 Users Say Thank You to endsormeans For This Useful Post:
Posts: 3,328 | Thanked: 4,476 times | Joined on May 2011 @ Poland
#14
So, it made create this post: http://talk.maemo.org/showthread.php...64#post1509664

There's really no use in planning right now, when we don't know how many people are willing to work on it. Two people won't work the same way as 10 people. So I'll stray for the in-depth discussion of the technical issues. We need to start from the HR part here.

I changed the OP to reflect the reality: such a project could be
1. a replacement for Maemo 5/MeeGo - for those who need it
2. a real GNU/Linux Maemo-like operating system - for those running Android
3. a mobile OS - for those running GNU/Linux-powered devices
4. a Fremantle like refuge - for the Jolla/Ubuntu users who don't like their OS

The project should be hardware-agnostic.
We should run upstream kernel - if you run upstream kernel, you should have the proper hardware. No further requirements (ok, you can't phone without proper hardware, but it's not the point)
__________________
If you want to support my work, you can donate by PayPal or Flattr

Projects no longer actively developed: here

Last edited by marmistrz; 2016-07-15 at 07:44.
 

The Following 2 Users Say Thank You to marmistrz For This Useful Post:
Posts: 3,074 | Thanked: 12,960 times | Joined on Mar 2010 @ Sofia,Bulgaria
#15
Originally Posted by Android_808 View Post
...
I could be using profiled, mce, etc etc from cssu in my GTK3 work if only I knew how to RE one closed library (libsystemui IIRC).
If you mean systemui, I can (and will) RE it, if needed, it is about 25k binary.

I can't say anything about battery life because I haven't tried any of it on a real device yet, only in amd64 Jessie vm.
Battery life depends on the kernel, in 4.8 we should have all the devices fully supporting PM and deep idle states, there is just a script needed to tell UART to autoidle (just google for it)
__________________
Never fear. I is here.

720p video support on N900,SmartReflex on N900,Keyboard and mouse support on N900
Nothing is impossible - Stable thumb2 on n900

Community SSU developer
kernel-power developer and maintainer

 

The Following 9 Users Say Thank You to freemangordon For This Useful Post:
Posts: 1,203 | Thanked: 3,027 times | Joined on Dec 2010
#16
Originally Posted by freemangordon View Post
If you mean systemui, I can (and will) RE it, if needed, it is about 25k binary.
It would be a great help down the line.

The replacement osso-* packages in cssu (devlock, tklock, powerkeymenu etc) will need it when I get round to porting them (http://maemo.org/packages/package_in.../0.2.0.18+0m5/).
 

The Following 5 Users Say Thank You to Android_808 For This Useful Post:
Posts: 3,328 | Thanked: 4,476 times | Joined on May 2011 @ Poland
#17
Rethought things, all the problems raised are completely on topic. Removed that useless comment from posts #1 and #14.

There's still one problem, even if we port h-d to gtk3. Apps.

As of today Debian lacks decent mobile apps. We have many of them, but many of them'll use libhildon+gtk2/qt4.

And if what we create is source-code incompatible with the old Maemo apps... we're screwed.

Besides - the Qt Components. But I'd see this as a second priority.
__________________
If you want to support my work, you can donate by PayPal or Flattr

Projects no longer actively developed: here
 

The Following User Says Thank You to marmistrz For This Useful Post:
Posts: 1,203 | Thanked: 3,027 times | Joined on Dec 2010
#18
Originally Posted by marmistrz View Post
As of today Debian lacks decent mobile apps. We have many of them, but many of them'll use libhildon+gtk2/qt4.

And if what we create is source-code incompatible with the old Maemo apps... we're screwed.

Besides - the Qt Components. But I'd see this as a second priority.
There is the potential possibility of being able to maintain some gtk2 apps for now by building maemo gtk2 and cssu libhildon.

Don't want to hijack thread by talking more about GTK3 stuff, but a lot of the work porting isn't too bad. Renamed classes/functions, GtkVBox/GtkHBox to GtkBox with orientation param. GtkTable to GtkGrid to avoid depreciation. Clutter is a nightmare along the lines of "Oh! Thats depreciated, use this. Oh, but we've replaced that with this. My bad, that's depreciated as well, use this one no one has got round to using yet".

I'm not as interested in maintaining apps though. As you state GTK mobile apps are few and far between. The stock apps (closed) obviously need replacing. MicroB we all know needs work to replace. If we create pure(r) GTK apps, they might get picked up by other projects. My plan has always been to use as many stock/upstream/standard packages as possible, just maintain our UI and let upstream handle as much of the base as possible.

Qt is a different issue that I'm yet to tackle. My ideas dating back to Qt5 talks were to make an external qt module for the custom classes. You've got the GTK/QT comatibility theme so as long as as much GTK stuff uses stock theme rules (ie not hildon specific) it should be able to use stock Qt5. I also have the souce for qmantle2 floating around for a potential experiment of a Lipstick based WM, and a Hildon UI based on a rework of Marxians componenets. Part of the idea here was that Nokia acquired Qt 18 months prior to Maemo/Moblin merger and used it in Harmattan. If this was the direction that they felt they wanted to take Maemo, maybe I should try to honour that instead.
 

The Following 3 Users Say Thank You to Android_808 For This Useful Post:
Posts: 3,074 | Thanked: 12,960 times | Joined on Mar 2010 @ Sofia,Bulgaria
#19
Originally Posted by Android_808 View Post
It would be a great help down the line.

The replacement osso-* packages in cssu (devlock, tklock, powerkeymenu etc) will need it when I get round to porting them (http://maemo.org/packages/package_in.../0.2.0.18+0m5/).
Ok, I'll start REing it in 2 weeks from now.
__________________
Never fear. I is here.

720p video support on N900,SmartReflex on N900,Keyboard and mouse support on N900
Nothing is impossible - Stable thumb2 on n900

Community SSU developer
kernel-power developer and maintainer

 

The Following 8 Users Say Thank You to freemangordon For This Useful Post:
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 20:38.