jessicant has quit [Remote host closed the connection]
jessicant has joined #maemo-leste
<kona>
freemangordon: tinymail doesn't build yet (and never has for me) but if you use ./autogen.sh --with-platform=maemo-leste && make you will see the current state.
<kona>
the error code mapping seems entirely incorrect (should use g_error_matches instead of switch, I guess) and it's possible that I misread the osso pdf reader example code and have cast streams incorrectly, until it builds it's not possible to test. will do some more reading on gio....
mardy has joined #maemo-leste
lyubov has quit [Ping timeout: 252 seconds]
lyubov has joined #maemo-leste
<freemangordon>
kona: I gained lots of experience back then when I was porting hildon-fm to gio, so I think I will be able to help
<freemangordon>
kona: there is g_io_error_from_errno, I will 'reverse' it in that switch
<Wizzup>
since freemangordon fixed the dsme problem
_inky has joined #maemo-leste
lyubov has quit [Ping timeout: 252 seconds]
lyubov has joined #maemo-leste
lyubov has quit [Ping timeout: 264 seconds]
lyubov has joined #maemo-leste
_uvos_ has joined #maemo-leste
<_uvos_>
Wizzup: no we will be needing that when dsme gives up its init personality to reduce its scope to a session manager, which is something we absolutly must do if we want to make it possible for other distrobutions to package the hildon stack or if we want to allow leste devices to properly allow the use of other desktops multiple usser sessions or different user names etc.
<Wizzup>
the current pr there doesn't do anything useful though?
<Wizzup>
but sure, feel free to leave it open I guess
<_uvos_>
it makes mce be started by openrc instead of dsme, we will need it then so i want to keep it around, i can also just merge it into some inactive branch instead of keeping it open if you like
<Wizzup>
no, whatever is fine
<_uvos_>
btw gsm dosent work for me on leste
<_uvos_>
on d4
<_uvos_>
if there is no umts i have to sett the tech type by hand
<Wizzup>
what do you mean specifically, 2g mode?
<_uvos_>
or it wont connect to 2g
<Wizzup>
It switches automatically for me
<_uvos_>
hmm
<_uvos_>
also i cant make it connect to edge data
<_uvos_>
even with qmicli
<_uvos_>
in los it works fine in the same location
<_uvos_>
btw i have never seen more than 2 bars in leste wheres android shows full signal
<_uvos_>
i have to compear db values
<Wizzup>
I have had full bars at least on 3g, but yeah
<_uvos_>
maybe android is just mor optimistic
<Wizzup>
usually it's less high
<Wizzup>
yeah probably
_uvos_ has quit [Ping timeout: 252 seconds]
uvos has joined #maemo-leste
inky_ has quit [Ping timeout: 252 seconds]
inky_ has joined #maemo-leste
pere has quit [Ping timeout: 252 seconds]
zhxt has quit [Ping timeout: 246 seconds]
^-^hi has joined #maemo-leste
<^-^hi>
What do you think about such an input method (in general, not for maemo): you press a button and a fully transparent window will let you hand-write (with some sort of evaporating ink so you don't run out of space) and it injects the input as keyboard input (with some special glyphs for backspace and ctrl and stuff)
<^-^hi>
Physical keyboards like that of N900 are the best but those that can fit on phones are often not good for when you speak a language that can't fit in them
<^-^hi>
also you have problems with some special characters.
<^-^hi>
A simple virtual keyboad like that of Maemo does the job but obstructs the application beneath it. (I haven't used it for more than texting, maybe it doesn't matter, but it seems it could matter)
<Wizzup>
Yes, we will have to improve h-i-m the future
<Wizzup>
to make the apps scale or something similar
<^-^hi>
Also virtual keyboards like that of Android is annoying and takes screen real-estate
<^-^hi>
Also the underlying toolkits need to be aware of the input method stuff, and how would they look when the keyboard pops up
<^-^hi>
You can't do stuff in minimal toolkits.
<^-^hi>
But when you press a button and then handwrite on something transparent you can enter everything while obstructing nothing, and the toolkit and the application don't need to worry about it.
<^-^hi>
You can also enter any glyph as you wish.
<^-^hi>
Do you see problems with this theoretical approach?
<^-^hi>
Oh and it would make sense when VNCing too.
zhxt has joined #maemo-leste
pere has joined #maemo-leste
<Wizzup>
uvos: hmm various xt862
<Wizzup>
seem to be mostly xt862
<Wizzup>
one says remanufactured in the philippines, droid 3 asurion
<mighty17[m]>
PVR:(Error): PVRDRIPlaneCreate: Failed to create share/scanout/cursor buffer [0, ]
<mighty17[m]>
PVR:(Error): PVRDRIBufferCreate: Failed to create plane [0, ]
<mighty17[m]>
CreateImageShared: Failed to create buffer
<mighty17[m]>
PVRImageDrawableGetNativeInfo: Image get buffers call failed
<mighty17[m]>
why does this happen? err 13 usually means no perms but i dont think thats related here
Buttercat has joined #maemo-leste
<mighty17[m]>
happens when i try to run supertuxkart on sgx540
<Buttercat>
Hello, do I understand correctly that there is currently no way to flash maemo leste on n900's eMMC?
<^-^hi>
Buttercat: It is possible, but why would you want to?
<Buttercat>
^-^hi: to spare a sd card, is it a bad idea?
<^-^hi>
Buttercat: Fremantle is practical for everyday use as phone, and has a lot of useful applications tailored for it.
<^-^hi>
Maemo leste not yet.
<Buttercat>
the thing is I don't really plan to use the n900 as a phone
<Buttercat>
would I forever be giving up the chance if I do flash maemo leste on eMMC?
<^-^hi>
There is a way for it on the leste website I think, look a bit around to find it.
<^-^hi>
Leste empties battery fast and lacks some stuff, but you can install new packages on it.
<Wizzup>
it's just easier to toy around on the sd card I'd say
<uvos>
Wizzup: ok and your original one was xt862 too right?
<uvos>
Wizzup: or 861?
<Wizzup>
xt862 I think
<Wizzup>
let me check
<uvos>
all of these where bought from us ebay?
<uvos>
right
<uvos>
?
<Wizzup>
yes
<Wizzup>
from ebay
inky has joined #maemo-leste
inky_ has quit [Ping timeout: 260 seconds]
<_inky>
>There is a way for it on the leste website I think, look a bit around to find it.
<_inky>
there is a way for pinephone.
lyubov has quit [Ping timeout: 252 seconds]
lyubov has joined #maemo-leste
<kona>
Buttercat: there are some directions to dual boot the n900 https://leste.maemo.org/Nokia_N900#Existing_Fremantle but i had to hold the 'u' key on the hwkbd when powering on, which seems to me to be the best kept secret in 1nearly two decades of Maemo.
<kona>
i feel like i just violated the first rule of maemo club or something.
<Wizzup>
hehe
<kona>
i keep fremantle around for a) nostalgia and b) to remind me how things worked when the behavior on leste doesn't match my memory (usually, it's my memory that is faulty ;) )
<uvos>
whats the u key supposed to do?
<uvos>
dosent seam to do anything on my n900
<bencoh>
he just said it was a secret :>
<kona>
^-^hi: the main challenge with something like the translucent / transparent window is how to balance the (scant) visual cues for people who can't use low contrast ui. even though i am such a person, being able to see my screen while typing is a clear benefit to me in many situations.
<^-^hi>
kona: using the inverse color from the background pixels
<^-^hi>
wouldn't look the best but would have highest contrast in any possible case
<kona>
the right mask would help a lot, for sure.
<kona>
oh, no, i see what you mean.
<kona>
yes, that would help a lot.
<^-^hi>
Like, the window is entirely transparent, entirely. Then the things you write in the inverse color
<^-^hi>
are in*
<kona>
freemangordon: hmm, maybe that would be better than gerror_matches... will you merge/fork my fork or do i continue work there?
<Buttercat>
kona: Thanks for the tip
<kona>
Buttercat: also, once u-boot is set up, looks to me like the u-boot menu only shows if i power on with the hwkbd open
<kona>
i should probably make a wiki account and do the edits.
<kona>
and sometimes the backlight doesn't turn on at the u-boot menu so you have to hold the screen at an angle or shine another light on it
<Wizzup>
yes please make a wiki account and edit as you please
<Wizzup>
backlight not turning on is a feature, btw
<kona>
sometimes it does turn on though, is there a secret handshake to be able to choose?
<Wizzup>
I think it depends on if it's powered on by cable insertion, and how full the battery is, and some other things
<kona>
oh, cool.
<^-^hi>
The way N900 screen works well in sunlight is so cool
<kona>
uvos: when using the flasher, i had to hold the u key while inserting the usb, otherwise the Quick method wouldn't boot my device.
<kona>
once i used the uboot method i didn't need it anymore.
<kona>
didn't need 'u' key anymore.
zhxt has quit [Ping timeout: 265 seconds]
<^-^hi>
Is VNC wasteful to use in input methods? It would make the compositing needed simple and would be make the input method very portable.
<Wizzup>
seems complex/wasteful yeah
<uvos>
never gona work
<uvos>
vnc needs to copy the frame back to the cpu to work
<uvos>
thats nasty pef wise
<uvos>
also what you propose is impossible on wayland
<uvos>
unless you want to implement an entire wayland compositor with this feature
<uvos>
on x you could do it but i would reccommend against the idea of inverting the colors just have the written stuff be a thin solid line
<uvos>
otherwise you need composing
<Wizzup>
ok, I think managed to clean the d3 covers, much better now
Buttercat has quit [Quit: Leaving.]
<freemangordon>
kona: I think it is better you to merge in your repo and continue work there. I can always pull/create another fork
<freemangordon>
kona: actually, is there anything else that has to be implemented in tinymail so far?
<freemangordon>
if not, then maybe it is better /me to just merge back in leste repo
<freemangordon>
I'll update debian/changelog when it comes to it
_inky has quit [Ping timeout: 265 seconds]
<^-^hi>
uvos: Aren't there vnc client for wayland?
inky has quit [Ping timeout: 265 seconds]
<^-^hi>
Also the VNC use could be limited to when using the input method. Though I am not sure myself how the server would see background without seeing the input method thing.
<^-^hi>
Maybe having the client write to framebuffer on another vtty or something nasty like that
<kona>
freemangordon: i think its just testing and the error func
<^-^hi>
uvos: VNC servers*
<^-^hi>
Maybe the input method writes on black background by default, but the background could optionally be written to by a primitive protocol for putting dirty rectangles there. So there are no strange dependencies necessary, but you can work transparency into it by VNC/X/other backends.
<Wizzup>
kona: what about gtkhtml?
<kona>
probably need that, too. i can work on that.
<uvos>
^-^hi: on wayland you cant draw over other windows
<uvos>
no thats not right
<uvos>
i mean on wayland you cant grab a frame from other windows to draw yourself
<uvos>
the vnc servers and sutch work by unevenly implemented protocolls other than wayland itslef
<uvos>
on wayland comps.
<^-^hi>
uvos: Aren't there VNC servers for major compositors?
<uvos>
sure this is what pipewire is ment to solve
<uvos>
afaik other solutions use kernel drm interfaces directly
<uvos>
neither of these are really portable
<uvos>
anyhow doing what you intend is fundamentaly a bad idea
<uvos>
copy + the redrawing is extreamly expensive
<uvos>
just create a window and make everything transparent other than the line the user draws
<uvos>
this will be a bit slow
<uvos>
but works on wayland and x
<uvos>
for more efficancy you can use the xshape extension on x
<^-^hi>
uvos: yes, but how would you draw a black line on black background?
<^-^hi>
hmm... I thought of a way
<uvos>
just draw a dashed line
<^-^hi>
You draw a black line and a white line inside it
<uvos>
white black wite
<^-^hi>
this way background has no effect anywhere
<Wizzup>
uvos: so the way I boot the d3 now is:
<Wizzup>
- boot to safestrap menu
<Wizzup>
- run a few commands (will provide in a sec)
<sicelo>
^-^hi: at some point in the history of Fremantle, you could use cellwriter, although now I don't remember what it looked like, even though I did use it for a while
<Wizzup>
of course this requires your kernel modules and such to be in place on the device
inky has joined #maemo-leste
<kona>
freemangordon: remind me where that uncrustify config lives? it seems to have scrolled out of my client buffer.
<Wizzup>
we should have that full uncrustity config + how to use it on the wiki IMHO
<Wizzup>
freemangordon: your full config for uncrustify
<Wizzup>
ah
<kona>
oh, i see.
<kona>
i thought you had one a few weeks back that was for general use in leste
<freemangordon>
no, there is no such, we were discussing to have one :)
<freemangordon>
Wizzup: we may use that one as a bse
<freemangordon>
*base
<freemangordon>
but, keep in mind that even uncrustify, being the most feature complete beautifier I found so far, cannot do all the formatting for you
<Wizzup>
at least the one you want :p
<freemangordon>
also, it cannot match QtCreator on 100% :(
<freemangordon>
QtCreator identifies (hardcoded) 2 x indent on line continuation. I cannot make uncrustify do it, neither I can disable that behaviour in QTCreator
<freemangordon>
s/identifies/indents
<freemangordon>
so, this is not exactly what I want but is close :)
<freemangordon>
Wizzup: no, it is not about what I want, it is about that it leaves some obviously bad formatting intact
<freemangordon>
unless it is my fault not being able to told it to behave all the times
<Wizzup>
fair enough
<freemangordon>
but, all the .c files in calendar-ui-widgets repo were formatted with config in the repo
<uvos>
its very likely a bad idea to base the coding standart on the hardcoded behavior of some obsucre editor
<freemangordon>
I created a key combo in QtCreator (ctrl-alt-U) that invokes uncrustify on the file I have on top, very handy
<freemangordon>
uvos: the only hardcoded thing in QtCreator beautifier is this 2 x indent
<freemangordon>
everything else is configurable
<freemangordon>
and uncrustify cfg I pushed actually changes it to 1 x indent
<freemangordon>
so in that regard it is not using the hardcoded value, the point is that I like QtCreator style more :)
<uvos>
ok
<uvos>
where is the expandsdcard script again?
<freemangordon>
'/etc' ?
<uvos>
yeah your right
<uvos>
wth is it doing in etc
<freemangordon>
ask whoever is the maintainer of hildon-base :p
<freemangordon>
"GtkHtml is being phased out in favor of WebKit/GTK+. "
<freemangordon>
libwebkit2gtk-4.0-dev:amd64 is what I have installed in the VM
<kona>
freemangordon: looks like i remember incorrectly.
<kona>
(re: expandcard)
<freemangordon>
but yeah, it links to gtk3
<uvos>
yeah the gtk2 version is libwebkitgtk+
<uvos>
thats unmaintined
<uvos>
i dont think there is a mantained html rendering engine for gtk2
<uvos>
but negatives are hard to prove ofc :)
<freemangordon>
I guess you are right, however, I think it is best to use what was maintained last
<Wizzup>
freemangordon: one thing about gtkhtml is that it is real simple and what modest used before
<Wizzup>
like I don't think it even supports js, does it?
<freemangordon>
I guess it does not
<Wizzup>
I mean, I think for proper html render with full feature we want something that uses newer gtk as well, but gtkhtml code is already there, so it might be simple to adjust to that first
<Wizzup>
(also I always turn off html email unless I cannot read something important without it)
<freemangordon>
hmm, ok
* freemangordon
wonders where that gtkhtml4 was
<uvos>
i would prefer email with no html over unmaintained html
<uvos>
strongly so even
<kona>
html email has always been a bad idea.
<freemangordon>
we can ship modest with html disabled by default
<kona>
but we won't change the world, html mail is here to stay, trackers and all. :)
<freemangordon>
so, does xdg-email support multiple attachments?
<uvos>
the script dosent afaik
<uvos>
also idk what happens if you add several to the mime message
<uvos>
should be fine
<uvos>
i think
<freemangordon>
if yes, I think it will be very simple to teach modest to support xdg - libmodest_dbus_client_compose_mail () is just one function call
<sicelo>
dreamer: heh, it's not x, so i am not sure x-forwarding is a criteria you can apply to it. there's waypipe for similar stuff on wayland though, iirc
<Wizzup>
freemangordon: cool
<freemangordon>
hmm, gtkhtml-4 requires gtk3
<freemangordon>
ok, centos7 provides gtkhtml3, I guess this is stable enough
<dreamer>
sicelo: I use x-forwarding on a daily basis
<dreamer>
have some `alias otplogin='oathtool --totp -b <secret> | xclip'` on a remote system for instance
<dreamer>
and other such tricks. + actual forwarding of x-programs
<dreamer>
then there are the typical X resize stuff with alt+mouse that afaik are not complete
<Wizzup>
freemangordon: is it still in debian repos? (gtkhtml3)
<freemangordon>
no
<freemangordon>
at least not in leste
<freemangordon>
however, it seems gtkhtml in maemo was heavily patched, I see 33 patches only one of which seems maemo specific
<Wizzup>
meh, let's hope that won't cause a lot of headache(s)
<freemangordon>
so I think we shall just use fremantle one
<Wizzup>
did anyone do any work on it ever since?
<Wizzup>
mhm
<Wizzup>
I mean 3.x
<freemangordon>
I think it won;t, those look like bug fixes
<freemangordon>
well, in fremantle it is 3.14, upstream has 3.91.92
<Wizzup>
once we use 3.x, let's make a bug report for upgrading
<Wizzup>
ah
<freemangordon>
but it is weird as upstrem 3.x requires gtk3
<Wizzup>
any reason not to go for 3.91.92 and ignore all non-hildon patches?
<Wizzup>
ah...
<Wizzup>
yeah gtk has silly numbering
<Wizzup>
just be careful not to get sucked into modernising the 3.14