mighty17[m] | freemangordon: weston 9 is fine? :P | 07:08 |
---|---|---|
freemangordon | what do you mean "fine"? | 07:11 |
mighty17[m] | well will it work with your mesa? | 07:13 |
mighty17[m] | freemangordon: weston 9 works with your mesa :o | 07:16 |
freemangordon | ah | 07:18 |
freemangordon | good | 07:18 |
freemangordon | so, there is some issue with sway? | 07:18 |
mighty17[m] | sway? i've been using phosh xD | 07:19 |
freemangordon | ah, yeah | 07:19 |
mighty17[m] | weston logs https://paste.debian.net/1219109/ | 07:20 |
mighty17[m] | freemangordon: actually, its using llvm | 07:21 |
mighty17[m] | or how do i confirm that? | 07:21 |
mighty17[m] | s/1219109/1219111/ | 07:27 |
mighty17[m] | freemangordon: looks like only weston works | 07:55 |
mighty17[m] | can you give phosh a try? | 07:55 |
mighty17[m] | or or I'll use xc-racer's mesa but apply your commits on top? | 08:00 |
mighty17[m] | i suppose i dont need to leste changes as well | 08:28 |
freemangordon | mighty17[m]: ok, I can give ti a try, but, care to link to a repo to use? | 08:37 |
freemangordon | or, it should be pre-build? | 08:37 |
freemangordon | "E: Unable to locate package phosh" | 08:38 |
mighty17[m] | https://gitlab.gnome.org/World/Phosh/phosh source code | 08:39 |
mighty17[m] | freemangordon: It's in debian | 08:40 |
freemangordon | it is not | 08:40 |
freemangordon | at least not in devuan we use | 08:40 |
mighty17[m] | In sid and bullseye | 08:40 |
freemangordon | good, but we are on older distro, iiuc | 08:41 |
freemangordon | anyway, will look at it when I have time | 08:42 |
mighty17[m] | Sure, till then I'll try getting your commits on xc racer's tree | 08:43 |
mighty17[m] | Idk which are important tho, probably not the rebases and leste ones for me | 08:43 |
freemangordon | I think it will be easier to merge xc racer's commits | 08:44 |
freemangordon | because my changes are based not his tree | 08:44 |
freemangordon | so there should be only few commits missing | 08:44 |
mighty17[m] | I know, but what if some commit breaks stuff for me, that's why I'd probably cherry pick | 08:51 |
mighty17[m] | freemangordon: basically all commits by you since `Oct 29, 2021` | 09:46 |
uvos | hi | 10:14 |
uvos | looks like i got baned again on libera chat | 10:15 |
uvos | <bencoh> funnily enough, pvr_dri points to nouveau_vieux.so btw" that cant be right | 10:17 |
uvos | build system must be confused somehow | 10:17 |
Wizzup | uvos: ugh @ ban | 10:17 |
bencoh | uvos: well, feel free to check http://muarf.org/~bencoh/maemo/leste/mesa-pvr-ti/ | 11:08 |
bencoh | may I ask why the Status tables on the n900/droid4 pages were renamed to "old status"? | 11:27 |
bencoh | is there a new per-device status table? | 11:27 |
Wizzup | the old status can go basically | 11:28 |
Wizzup | the new status is on the top right of the page | 11:28 |
bencoh | the "Software features"? | 11:29 |
Wizzup | yeah | 11:29 |
Wizzup | probably the old status can go | 13:56 |
uvos | new sphone: storage plugin api implemented via rtcom and used for call history (not sms/messages yet) by gui, various small improvements | 14:51 |
uvos | it uses local-uid as /sphone/$(BACKEND)/%(LINE_ID) | 14:53 |
uvos | it absoulty needs to know the backend a call/msg was made on | 14:53 |
uvos | but im open to alternative routes for storing this | 14:54 |
uvos | not sure what the HEADERS are for/should contain so sphone ignores this, Wizzup if you figure this out pleas do tell | 14:54 |
dsc__ | inside the VM, with Dorian, when you click this button: https://i.imgur.com/ED3wWiP.png | 14:54 |
Wizzup | what is line-id? | 14:55 |
dsc__ | screen will go all-black, and only option is to reset | 14:55 |
dsc__ | afterwards; every time you open Dorian, it will go all-black | 14:55 |
Wizzup | dsc__: hm sounds like your VM has trouble with rotated screens | 14:55 |
dsc__ | unless you remove /home/user/.config/Pipacs/Dorian.conf | 14:55 |
dsc__ | ah | 14:55 |
Wizzup | dsc__: let me try it in my vm momentarily | 14:55 |
uvos | Wizzup: sphones internal name for phone number or user name or whatever the $(BACKEND) needs to connect to this person. | 14:56 |
Wizzup | what phone number is that? the person that calls you? | 14:56 |
uvos | same as remote-uid i rtcom (and sphone sets it here to) | 14:56 |
uvos | yes the id of the remote party | 14:56 |
Wizzup | that's wrong | 14:56 |
Wizzup | sqlite> select distinct local_uid from events; | 14:56 |
Wizzup | ring/tel/ring | 14:56 |
Wizzup | sofiasip/sip/merlijnwajer_40ekiga_2enet0 | 14:56 |
Wizzup | spirit/skype/wizzy_2e_2e0 | 14:56 |
uvos | in backend dependant form | 14:56 |
Wizzup | remote_uid is the other party | 14:57 |
Wizzup | local_uid is just you | 14:57 |
uvos | ok | 14:57 |
uvos | so where shal i shove the backend? | 14:57 |
Wizzup | this should be apparement from fremantle db | 14:58 |
Wizzup | apparent | 14:58 |
Wizzup | typically it goes in remote_uid, but I cannot comment on the exact form | 14:58 |
Wizzup | it looks like for tp-ring the remote_uid is just the number that calls you, for sip it's the sip:foo number that calls you | 14:58 |
Wizzup | and for irc etc it's the irc nick that chats (not sure how that works in groups atm) | 14:59 |
Wizzup | all of this can be set up on fremantle with ease fwiw | 14:59 |
uvos | well problem is this is all very ill defined | 14:59 |
Wizzup | (and yeah I've been overloaded with real life work so didn't get much further yet :-)) | 14:59 |
uvos | seams like they just have backends randomly insert different strings | 14:59 |
Wizzup | from my notes: | 14:59 |
Wizzup | local_uid TEXT, -- plugin local uid ('account' on a plugin/protocol) | 14:59 |
Wizzup | local_name TEXT, -- seems to own irc nickname, etc <SelfHandle> for telepathy-ring | 14:59 |
uvos | so local_uid should just be sphone/something then? | 15:00 |
Wizzup | remote_uid TEXT, | 15:00 |
Wizzup | channel TEXT, -- channel for an event | 15:00 |
Wizzup | yes, but this must also be registered as service I think | 15:00 |
uvos | no | 15:00 |
uvos | servcies are seperate | 15:00 |
Wizzup | right, yeah | 15:00 |
Wizzup | just checked with sql | 15:00 |
uvos | so how about local_uid: sphone/sphone remote_uid: %(BACKEND):(%LINE_ID), local_name: unix username | 15:01 |
Wizzup | well, I gave you an example for telepathy-ring, the remote_uid is just the phone number | 15:02 |
Wizzup | I don't see the point of the unix username, but for telepathy-ring the local_name is not too relevant anyway | 15:02 |
Wizzup | (in empathy it's also '<SelfHandle>') | 15:02 |
uvos | Wizzup: right except the example is ill defined for modem calls its just the number and for sip is the protcoll (sip) and then the number | 15:04 |
uvos | sphone dosent/ dosent want to treat ofono calls as special somehow | 15:05 |
Wizzup | I don't understand | 15:06 |
uvos | if i place just the number into remote-uid and have an entry for +4945487125457 | 15:07 |
uvos | how is sphone supposed to know this was a telegram call and calling back on this event shal use that backend instead of ofono | 15:08 |
Wizzup | the local_uid indicates the plugin used | 15:08 |
Wizzup | there's also the event type | 15:08 |
Wizzup | the event type is normal call, or sip call, etc, afaik | 15:08 |
Wizzup | so that way you could know | 15:09 |
uvos | no | 15:09 |
uvos | those dont exist in the plugins we have atleast | 15:09 |
uvos | you could define those sure | 15:09 |
Wizzup | 'those'? | 15:09 |
uvos | more event types | 15:09 |
uvos | "the local_uid indicates the plugin used" no it dosent | 15:09 |
Wizzup | sqlite> select * from eventtypes; | 15:09 |
Wizzup | 1|RTCOM_EL_EVENTTYPE_CALL|1|Call | 15:09 |
Wizzup | 2|RTCOM_EL_EVENTTYPE_CALL_MISSED|1|Missed call | 15:09 |
Wizzup | 3|RTCOM_EL_EVENTTYPE_CALL_VOICEMAIL|1|Voicemail message | 15:09 |
uvos | its just a phone number | 15:09 |
Wizzup | uvos: no, local_uid is not a phone number | 15:09 |
Wizzup | local_uid is ring/tel/ring for example | 15:09 |
Wizzup | remote_uid is the phone number | 15:10 |
uvos | er right | 15:10 |
uvos | so have local_uid as sphone/$(BACKEND) | 15:10 |
uvos | and remote_uid as just the line_id | 15:11 |
Wizzup | that's how fremantle does it it looks like | 15:11 |
Wizzup | there might be more to it and in particular the chat types and stuff I haven't grasped fully | 15:11 |
uvos | well thats not terribly important rn | 15:11 |
uvos | for sphone at least | 15:12 |
Wizzup | example for sip calls: | 15:12 |
Wizzup | 33771|1|1|1629194398|1629194396|0|0|1|0|0|0|sofiasip/sip/sip_2exs4all_2enl0||sip:+3161xxxxxxx@sip.xs4all.nl||| | 15:12 |
uvos | anyhow the functions to translate sphones internal reprisentation -> rtcom and back are here in this plugin: https://github.com/maemo-leste/sphone/blob/f1881b09c414835f5ed061c2b7a751ee4c14932b/src/modules/store-rtcom.c#L129 | 15:14 |
uvos | rtcom_el_iter_get_values is fun | 15:15 |
uvos | because the values of the entrys just randomly change (not defined anywhere) names | 15:15 |
Wizzup | I don't understand what you mean | 15:17 |
uvos | im just harping on the api | 15:17 |
uvos | you RTCOM_EL_EVENT_SET_FIELD(ev, event_type, g_strdup("RTCOM_EL_EVENTTYPE_CALL_MISSED")); | 15:18 |
uvos | (with RTCOM_EL_EVENTTYPE_CALL_MISSED being a magic string) | 15:18 |
Wizzup | like I said, those need to be defined in some headers | 15:18 |
Wizzup | parts of this were closed source, and we probably lack those headers | 15:18 |
uvos | then you cant get event_type | 15:18 |
Wizzup | ? | 15:18 |
uvos | because its event-type-id now and magicly became a int | 15:18 |
uvos | but if you add start_time it gets translated to start-time | 15:19 |
uvos | and stays an int | 15:19 |
Wizzup | of course the database uses ints | 15:19 |
Wizzup | you can probably set the "event-type-id" properly | 15:19 |
Wizzup | property* | 15:19 |
Wizzup | (I haven't checked, just a guess) | 15:19 |
uvos | Wizzup: right but the api just randomly translates some strings to ints and not others | 15:20 |
uvos | and your suposed to just now | 15:20 |
uvos | it also translates the field names | 15:20 |
uvos | and your suposed to just know that the input field name free_text becomes free-text when you need the field again | 15:20 |
uvos | its a mess | 15:20 |
Wizzup | I never used RTCOM_EL_EVENT_SET_FIELD | 15:20 |
Wizzup | I used the gobject properties | 15:20 |
Wizzup | which seemed like how they want it to be used | 15:21 |
Wizzup | but again I cannot attack or defend the API | 15:21 |
uvos | i kind of doubt that they have that macro and use it in the unit test beacuse they dont want it used but ok | 15:23 |
Wizzup | uvos: the unit test might not be the best example of public api | 15:24 |
Wizzup | did you look at code of rtcom-eventlogger-ui as well? | 15:24 |
Wizzup | I don't know if it is any different | 15:24 |
uvos | its N/A since it dosent add any events | 15:26 |
Wizzup | I think it had code to add events actually | 15:26 |
Wizzup | which is commented in the main() | 15:26 |
Wizzup | in the example | 15:26 |
Wizzup | see log_some_stuff | 15:27 |
uvos | RTCOM_EL_EVENT_SET_FIELD | 15:27 |
Wizzup | look that uses the string api | 15:27 |
uvos | so yeah | 15:27 |
Wizzup | looks like* | 15:27 |
Wizzup | in any case what I still want to clear up how we can efficiently separate out different protocols | 15:27 |
Wizzup | I'd like to split sip/telegram/signal/ring/xmpp or at least filter by them | 15:28 |
Wizzup | but in the current plugins xmpp/telegram/signal are all the same rtcom plugin | 15:28 |
Wizzup | and the same event types | 15:28 |
Wizzup | so I guess there's just local_uid for that | 15:28 |
Wizzup | but the local_uid is a string and we'd have to match a part of the string or something, which is yuck | 15:28 |
uvos | yeah right | 15:29 |
Wizzup | since they all use service_id RTCOM_EL_SERVICE_CHAT | 15:29 |
uvos | thats what sphone dose rn | 15:29 |
uvos | ie match sphone/ofono | 15:29 |
uvos | and call with ofono | 15:29 |
Wizzup | I don't want to do that really | 15:29 |
uvos | right | 15:29 |
uvos | also same problem with RTCOM_EL_SERVICE_CALL | 15:29 |
Wizzup | but I will worry about this once the telepathy logging works | 15:29 |
Wizzup | wrt call, you mean sip vs ring? | 15:29 |
uvos | i assumed RTCOM_EL_SERVICE_CHAT was for messages | 15:30 |
Wizzup | oh, good point | 15:30 |
uvos | or telegram whatsapp whatever | 15:30 |
Wizzup | I'd have to check skype calls | 15:30 |
uvos | not just "sip" | 15:30 |
Wizzup | I can check that actually | 15:30 |
Wizzup | sec | 15:30 |
Wizzup | sqlite> select distinct event_type_id from events where local_uid='spirit/skype/wizzy_2e_2e0'; | 15:31 |
Wizzup | 1 | 15:31 |
Wizzup | and: | 15:31 |
Wizzup | sqlite> select * from eventtypes where id=1; | 15:31 |
Wizzup | 4 | 15:31 |
Wizzup | 6 | 15:31 |
Wizzup | 1|RTCOM_EL_EVENTTYPE_CALL|1|Call | 15:31 |
Wizzup | sqlite> select * from eventtypes where id=4; | 15:31 |
Wizzup | 4|RTCOM_EL_EVENTTYPE_CHAT_MESSAGE|2|Normal message | 15:31 |
Wizzup | sqlite> select * from eventtypes where id=6; | 15:31 |
Wizzup | 6|RTCOM_EL_EVENTTYPE_CHAT_ACTION|2|Action message | 15:31 |
Wizzup | looks like you're correct | 15:31 |
Wizzup | uvos: got any idea on how to solve above problem? | 15:48 |
Wizzup | apart from string-matching local_uid | 15:48 |
Wizzup | we could make it different services with shared event types | 15:48 |
Wizzup | although I am not sure if that breaks the model somehow | 15:48 |
Wizzup | uvos: potentially flags.... somehow | 15:49 |
Wizzup | or we could change the database model. | 15:49 |
Wizzup | and provide a migration tool | 15:49 |
uvos | downside to different services is that you need a plugin for it | 15:50 |
uvos | so everything needs to register a plugin for dubious benefit | 15:50 |
uvos | sure we could add a packend field that gets filled with a uuid | 15:50 |
Wizzup | well I don't see why all chat really fits in one plugin though | 15:50 |
uvos | no idea what the flags are for | 15:50 |
Wizzup | by that logic I think sms and chat should be the same plugin | 15:51 |
Wizzup | uvos: https://dpaste.com/3PLPNGE3H | 15:51 |
uvos | the question is what is the point of the plugins even | 15:51 |
Wizzup | they offer helper functions for plugin specific code | 15:51 |
uvos | "the plugins exist to offer helper functions to the plugins" | 15:52 |
uvos | heh | 15:52 |
uvos | no seriously i dont know what the benefit of having the plugins is over RTCOM_EL_SERVICE_CALL just being a enum | 15:52 |
Wizzup | uvos: did you look at the plugin code? | 15:53 |
uvos | i did | 15:53 |
Wizzup | btw, the remotes table might also be relevant somehow, but IDK who writes to it | 15:53 |
Wizzup | I think it maps local_uid, remote_uid to remote_name and osso abook id | 15:54 |
uvos | the plugins really just seam like a half implemented idea that dident go anywhere | 15:55 |
uvos | like they where supposed to have wrappers for adding new events in an easy way without the insane RTCOM_EL_EVENT api | 15:55 |
uvos | and sutch | 15:55 |
uvos | ie abstract the database more, rn rtcom-eventlogger is a farily thin wrapper around the raw sql database | 15:56 |
Wizzup | well, we can do that | 15:57 |
uvos | not sure we want tho | 15:57 |
uvos | since then you need to maintain a rtcom plugin for every protocoll | 15:57 |
Wizzup | why is that? | 15:58 |
uvos | seams not sufficantly benifical | 15:58 |
Wizzup | ok so what about another table protocol and give events a protocol_id ? | 15:58 |
uvos | sure | 15:58 |
uvos | how is protocol_id generated? | 15:58 |
uvos | just have the issuer generate a uuid? | 15:59 |
Wizzup | well I would suggest it gets inserted once and doesn't change - i.e. you can't delete it | 15:59 |
Wizzup | no, I would suggest the protocol table is basically (1, 'telepathy-ring'), (2, 'telepathy-morse'), etc | 15:59 |
uvos | ok so you want to add a function to eventlogger that inserts a new protocol | 16:00 |
Wizzup | yes, probably to the plugins ;) | 16:00 |
Wizzup | since we have no other way of adding things to the db | 16:00 |
uvos | ie int add_some_protocol(const char *name); | 16:00 |
Wizzup | (upon init) | 16:00 |
Wizzup | I wouldn't suggest random applications add a protocol | 16:01 |
Wizzup | I would suggest that's a well controlled and defined list | 16:01 |
uvos | hmm | 16:01 |
uvos | not sure its great that there is then a defined list of protocols you cant change as an app developer | 16:02 |
uvos | like i implement $(SHINY_NEW_PROTOCOL) | 16:02 |
uvos | and then i cant log its events | 16:02 |
Wizzup | and then you get it packaged for maemo/telepathy | 16:02 |
uvos | without submitting a pr etc | 16:02 |
Wizzup | and then we add it :) | 16:02 |
uvos | yeah | 16:02 |
Wizzup | as a dev you can do one INSERT INTO into db the for testing probably | 16:02 |
uvos | but thats not whats gona happen in practice | 16:02 |
uvos | in practice the person with $(SHINY_NEW_PROTOCOL) is gonig to just go | 16:03 |
uvos | oh my protocol is kinda like xmpp so lets just log events like that instead of this headace of geting a patch upstream somewhere | 16:03 |
Wizzup | I think the one detail you are omitting is that when someone implements a tp plugin | 16:04 |
Wizzup | they don't need to take care of the logging | 16:04 |
Wizzup | we have a program that logs tp channels to the db | 16:04 |
uvos | the world dosent nessecarly revolve around tp | 16:04 |
Wizzup | and that is abstracted no matter the protocol | 16:04 |
Wizzup | well rtcom kinda does | 16:04 |
Wizzup | at least in maemo fremantle | 16:04 |
uvos | not at the moment | 16:04 |
uvos | not really | 16:04 |
Wizzup | I haven't discovered anything in there that is not TP | 16:04 |
Wizzup | with ~10 years of usage and events | 16:05 |
uvos | rtcom-eventlogger currently dosent care mutch about where the events come from | 16:05 |
uvos | lets not fix it to tp | 16:05 |
Wizzup | it is not, but our UI code will be | 16:05 |
Wizzup | otherwise we will need to add random plugins for every protocol | 16:06 |
Wizzup | to the UI as well | 16:06 |
Wizzup | which is not scalable | 16:06 |
uvos | no you makeing the assumption that your ui and stack will be the only thing running | 16:06 |
Wizzup | I am assuming that that is the maemo chat integration and other things that don't integrate won't use rtcom :P | 16:06 |
uvos | but people will not like you ui and want to run $(RANDOM_MATRIX_CLIENT) instead | 16:06 |
Wizzup | yeah but I don't think that would log to rtcom | 16:06 |
uvos | and maybe they want to hildonize $(RANDOM_MATRIX_CLIENT) | 16:07 |
uvos | we should allow it | 16:07 |
Wizzup | it could, but I don't understand why they would | 16:07 |
Wizzup | since telepathy already does it | 16:07 |
Wizzup | (telepathy-tank, iiuc) | 16:07 |
Wizzup | supporting libpurple next to tp on the other hand seems interesting to eventually try | 16:07 |
uvos | point is if you dont allow a ecosystem of $(RANDOM_MATRIX_CLIENTS) ported from elsewere to exist on our OS by forceing everyting through tp | 16:08 |
uvos | they wont | 16:08 |
Wizzup | they can exist, but I am not sure why they would log to rtcom? | 16:08 |
Wizzup | they're probably happier using whatever existing logging they have | 16:08 |
uvos | why not? better integraion | 16:08 |
uvos | maybe so, but closing the door is unwise | 16:08 |
Wizzup | slightly better integration, proper integration is in conversations :P | 16:08 |
Wizzup | I'm not really closing the door at all I think | 16:09 |
Wizzup | it's an open platform and people can do what they want | 16:09 |
uvos | conversations can not and will never fit all needs | 16:09 |
Wizzup | I was just trying to figure out a way to make the db schema more amendable to many different tp plugins | 16:09 |
uvos | and this way | 16:09 |
uvos | is bad | 16:10 |
Wizzup | what's bad about it? | 16:10 |
uvos | we just discused that | 16:10 |
Wizzup | I don't see it | 16:10 |
uvos | "adding a proctocoll requires a patch upstream" | 16:10 |
uvos | to the table | 16:11 |
Wizzup | I would say proper integration requires working with upstream, which is common in FOSS | 16:11 |
Wizzup | doesn't stop anyone from just doing INSERT () from their application | 16:11 |
Wizzup | but sure it could a call that does the ~5 line insert code | 16:11 |
Wizzup | I think it's mostly a non-issue | 16:11 |
uvos | we definatly dont want people doing sql calls directly. | 16:12 |
uvos | i think its very mutch an issue | 16:12 |
uvos | compeard to what you suggest i very mutch prefer fremantle status quo even | 16:13 |
Wizzup | only tp? | 16:13 |
Wizzup | (that's fremantle status quo) | 16:13 |
Wizzup | even skype went through TP on fremantle | 16:14 |
Wizzup | they just didn't let you filter on telepathy plugin (protocol) in the UI | 16:14 |
Wizzup | which is what this is mostly about | 16:14 |
Wizzup | at least that's my understanding | 16:14 |
uvos | well they have to strcmp local_uid somewhere | 16:15 |
uvos | to figure out what protocol to use | 16:15 |
uvos | for reply etc | 16:15 |
Wizzup | I don't think they need | 16:16 |
Wizzup | I don't think they need to* | 16:16 |
Wizzup | conversations all revolves around contacts mostly | 16:16 |
Wizzup | and for calls you get the option to use sip (accounts) or regular | 16:16 |
Wizzup | but yeah there must be some way they do that | 16:17 |
Wizzup | in any case I'm more worried about storing plugin specific stuff through tp to begin with | 16:17 |
uvos | ok | 16:19 |
uvos | well youll figure something out | 16:19 |
Wizzup | hopefully :P | 16:20 |
uvos | ill continue to do my thing, adding conversation a thread view to sphones sms-history is next | 16:20 |
uvos | oh btw the dialer | 16:26 |
uvos | dosent force portrait anymore | 16:26 |
Wizzup | <3 | 16:26 |
uvos | instead the keypad is hidden | 16:27 |
Wizzup | I'll try it on my n900 momentarily :-p | 16:27 |
uvos | when in landscape | 16:27 |
Wizzup | do you know what it looks like in fremantle btw? | 16:27 |
Wizzup | I can make a screenshot now if you want | 16:27 |
uvos | yes i do | 16:28 |
Wizzup | it's basically split in half | 16:28 |
uvos | i know | 16:28 |
Wizzup | right half is the dialer numbers | 16:28 |
Wizzup | ok ok | 16:28 |
Wizzup | :) | 16:28 |
uvos | i honsely i think its fine rn | 16:28 |
uvos | without the numbers | 16:28 |
Wizzup | I'll check it out | 16:28 |
uvos | hmm maybe on n900 its less fine | 16:29 |
uvos | (no number hwkeys) | 16:29 |
Wizzup | it does support that | 16:29 |
Wizzup | I just tried it | 16:30 |
Wizzup | the input field is set to a special input mode | 16:30 |
uvos | support what? | 16:30 |
Wizzup | so 's' is automatically '+' | 16:30 |
uvos | yeah that | 16:30 |
Wizzup | and 'w' is automatically '2' | 16:30 |
uvos | ok | 16:30 |
uvos | ok | 16:30 |
uvos | btw the hildon opening animation is really janky for sphone | 16:37 |
uvos | because it launches and then infroms the primary instance and then exits immitaly | 16:37 |
uvos | and then the window pops up | 16:38 |
uvos | modest also has this problem | 16:38 |
uvos | not sure if there is a solution to tell hildon to keep the rectangle even if the process exits | 16:38 |
Wizzup | what should I see with modest? | 16:38 |
uvos | with both sphone and modest the rectangle/screenshot spawns then hangs while the new window appears then the new window appears | 16:39 |
uvos | looks janky | 16:39 |
Wizzup | hm I am not sure if I see it with modest | 16:39 |
Wizzup | let me upgrade sphone | 16:39 |
uvos | probubly cant see it on n900 (its to slow) | 16:40 |
Wizzup | I see it on d4 I think | 16:41 |
Wizzup | kind of a minor detail but yeah :p | 16:41 |
uvos | maybe a .desktop key that tells hildon: this launches really fast dont bother with the animation | 16:43 |
uvos | is in order | 16:43 |
Wizzup | that could be a solution yeah | 16:44 |
Wizzup | I think the phone app on fremantle has the same problem | 16:44 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!