Notices


Reply
Thread Tools
Posts: 3,019 | Thanked: 12,498 times | Joined on Mar 2010 @ Sofia,Bulgaria
#171
Originally Posted by Android_808 View Post
Sick of this recurring illness now.



Updated my VBox installation earlier and my Debian VM in the hope that I can resume work on this again very soon. I noticed in the fremantle-gtk2 repo that you have removed the GTK module and opted for a forked GTK instead. Were you hitting a roadblock/problem with the module method?
Definitely, too much stuff in those private structs needs to be accessed, esp for GtkTreeView/GtkIconView (but not only), it will become an unmanageable mess at some point if I have to LD_PRELOAD almost all exported GTK functions, while copying all of the GTK code. So we had a discussion with Wizzup and parazyd (the guys that I am expecting to create devuan-maemo repo) and we decided that GTK fork is the only sane option.

In terms of GTK3, I know the module method will not guarantee 100% compatibility with the existing Hildon API. GtkIMContext related code, as previously mentioned, is a no go due to being unable to access the context.
This leaves me with a few choices, do I keep as much API in tact as possible or ditch compatibility like in my original attempt and create a cut down or API incompatible library (like with GTK2 and 3), following the deprecation messages left by the original devs.
The biggest problem I see is with GtkTreeView and GtkIconView code, they are heavily patched in maemo to bring the beauty of those widgets there and to provide touch support. On the other hand it might be that it will be easier in GTK3 as aiui it has touch support already implemented.

Making API incompatible library will somehow make the effort pointless IMO, as there will be no code that will compile without major rewrite. On the other hand it is inevitable because of GTK2/3 incompatibilities. Dunno.

Another option would be to suspend work on hildon-desktop GTK3 and instead add GTK3 support to the fremantle-gtk2 environment.
I am not sure I understand what you mean, could you elaborate.

On a side note - I am having very big problems with hildonfm - it turns out I have to rewrite it almost fully to be compatible with gio. What I have done so far is maybe 30% of the needed changes. But...
__________________
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 10 Users Say Thank You to freemangordon For This Useful Post:
Posts: 1,095 | Thanked: 2,522 times | Joined on Dec 2010
#172
i'm thinking building libhildon3 and shipping it as an optional file for fremantle-gtk2. Like running a gtk3 app under xfce or any other gtk2 desktop. it should work with gtk2 h-d as it specifies an xatom for matchbox to handle app menu.

This way it can be an optional, experimental component focused on getting gtk3 apps hildonized.
 

The Following 14 Users Say Thank You to Android_808 For This Useful Post:
Posts: 3,019 | Thanked: 12,498 times | Joined on Mar 2010 @ Sofia,Bulgaria
#173
That one was tough https://github.com/fremantle-gtk2/li...8e7b0b69bf4af7

Still lot to do (implement mounts/volumes support, move to GFile from GtkFilePath, implement tracker support, ...), but at least I am on the right track finally

EDIT: add screenshots
Attached Images
  
__________________
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


Last edited by freemangordon; 2017-05-11 at 07:20.
 

The Following 27 Users Say Thank You to freemangordon For This Useful Post:
Posts: 1,095 | Thanked: 2,522 times | Joined on Dec 2010
#174
Been playing around with some ideas lately, hence no update.

I'm currently working on an idea for a replacement of HildonWindowStack and HildonStackedWindow in a stock build of GTK3, making the functionality free from requiring matchbox/hildon-desktop. I just need a way to change the close icon at the moment. If I remove the default close icon and replace it with a custom button I seem to lose the WM theme based style. I'll post a basic working example when done.
 

The Following 12 Users Say Thank You to Android_808 For This Useful Post:
Posts: 106 | Thanked: 598 times | Joined on May 2016
#175
Originally Posted by Android_808 View Post
Been playing around with some ideas lately, hence no update.

I'm currently working on an idea for a replacement of HildonWindowStack and HildonStackedWindow in a stock build of GTK3, making the functionality free from requiring matchbox/hildon-desktop.
Is this to get Hildon apps running in other environments?

Not sure if this is the right topic to post this, but I wanted to sum up some ideas and experiments I had on running Fremantle UI on relatively modern phones

I used Arch Linux ARM rootfs with custom PKGBUILDs for packages in fremantle-gtk2 repo (I will upload them after some cleaning up if anyone is interested) in chroot under SailfishOS. Arch Linux in part because it was easy to setup and Iím more familiar with its packaging compared to Debian/Devuan, but it shouldnít be a problem to do the same once Maemo packages for Devuan are built.

Testing under SailfishOS allowed to skip initial boot issues, such as properly starting Android bits, but this isnít required of course. There is Halium project effort by Plasma Mobile and UBPorts devs which can be useful to built proper distro when needed.

Android uses different graphics stack compared to normal Linux: SurfaceFlinger acts as display server/compositor and talks to Hardware Composer (HWC) API, while gralloc is used for memory buffer allocations. libhybris has the code to provide Wayland integration to Wayland compositor (which then speaks to HWC instead of SurfaceFlinger) and Wayland EGL clients.

hildon-desktop is Xorg compositor/window manager instead and uses clutter, which requires OpenGL (ES) acceleration. The problem is that there is no intergration provided for X server windowing platform in libhybris. There are some ways to workaround that.
  • Using native graphics drivers
    Qualcomm SoC devices: there is open-source driver for Adreno graphics found in Qualcomm SoCs - Freedreno. It should work just fine for Xorg OpenGL acceleration, but it requires either using fairly new mainline kernel (isnít the case with Android devices) or backporting DRM subsystem to older one. Itís mostly used with Qualcomm development boards, such as DragonBoard. The only phone there were efforts to get it working with is Nexus 4, which is old by now.

    MediaTek SoC devices: most MediaTek SoCs come with Mali graphics, which provide Linux userspace binaries, but it seems they need to be built for each specific SoC and only silicon manufacturers have license to Mali DDK for that.

    There are also some SoCs with PowerVR graphics and lately they appeared in Chromebooks with mainline kernel support for DRM/modesetting, but this canít be easily backported to phone SoCs either.
  • Adding X server platform integration to libhybris
    It should be doable to add X server integration as EGL windowing system in libhybris the way it was done for Wayland compositors/client, but Iím not familar enough with Xorg architecture to understand how to do it right. I tried doing it based on the idea/code for Raspberry Pi, which involves offscreen rendering and using XPutImage/XShmPutImage to output result. While donít need to use glReadPixels(), since gralloc provides access to graphics memory buffer, itís still slower than it needs to be and involves doing extra copies. My implementation in libhybris works as proof-of-concept, but seems to suffer from race conditions and surely can be improved.

    I wonder if there is an easy way to assotiate XPixmap with arbitrary value (gralloc buffer handle) and modify Xorg server to access pixmap data through it when available (via some kind of extension?). This way extra copies could be avoided.
  • Partially using Wayland
    Proper wayland integration would require moving to GTK+ 3 (GTK+ 2 apps donít support Wayland, but can be launched via XWayland integration) and either rewrite of hildon-desktop to act as display server/Wayland compositor, or using different compositor/window manager, such as Mutter from GNOME Shell or KWin.

    Instead I tried to make a hack of xlib Cogl windowing system integration to make it connect both to X server and Wayland compositor. This way hildon-desktop can still act as X (Xwayland in this case) compositor, but OpenGL will render to Wayland compositor and be overlayed on top of Xwayland output (I modified QtWayland example to act as such compositor).

    It works fastest on devices I could test (Xiaomi Redmi Note 2, OnePlus 2, Moto Z Play), but is pretty quirky to say the least. Screen capture by X server apps wonít work, unless itís mixed with previous approach, and Iím not sure what to do with other X server clients using OpenGL, unless they also run fullscreen.

I tried to cover only graphics for now. Other subsystems adaptations could be probably reused from SailfishOS/UBPorts, since they bind Android drivers to pretty standard Linux components (for example ofono/telepathy-ring for telephony, PulseAudio, gstreamer for hardware decoding/camera access).
 

The Following 9 Users Say Thank You to TheKit For This Useful Post:
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 18:25.