Active Topics
-
How many of you still use N900 as main phone? (595)
to Community by deutch1976 - 2 days, 4 hrs ago -
Big news (7)
to OS2008 / Maemo 4 / Chinook - Diablo by endsormeans - 3 days, 13 hrs ago -
Firefox with Leste (8)
to Maemo 7 / Leste by endsormeans - 3 days, 13 hrs ago -
Which is the best N95? What software modifications could be made to it? (3)
to General by Kalatti - 6 days, 13 hrs ago -
Installing CSSU Stable in year 2024 (2)
to Maemo 5 / Fremantle by teroyk - 6 days, 21 hrs ago - more...
 |
Amboss |
2012-07-25
, 21:28
|
|
Posts: 237 |
Thanked: 502 times |
Joined on May 2010
@ Mittelfranken, Germany
|
#241
|
Originally Posted by RobertMe
Though it is nice to always make use of the newest features available, having a version based on stable XBMC is useful as well. If it is possible to have a feature on Eden, why do you want to make it depend on the unstable Frodo. If the remote is not stable, that's fine, but as for the main component of my media world I like to stick to stable.
| The Following User Says Thank You to Amboss For This Useful Post: | ||
|
|
2012-07-26
, 05:36
|
|
Posts: 59 |
Thanked: 168 times |
Joined on Jun 2012
|
#242
|
As I said, we didn't really come to a conclusion on how to add Frodo support and didn't pick a date to release a Frodo only version. So it may as well be long after the Frodo release until the remote gets a Frodo release. And about dropping support for some things in Eden (buttons on gesturepad and keyboard), (some of) those are still using legacy commands, and in Frodo there are new JSON RPC based commands, so it gives the advantage of dropping the legacy command support. But here also, maybe we will built in a switch for Eden and Frodo support so it will still use the legacy commands for Eden.
| The Following User Says Thank You to RobertMe For This Useful Post: | ||
|
|
2012-07-26
, 09:34
|
|
Posts: 49 |
Thanked: 103 times |
Joined on Apr 2010
|
#243
|
Originally Posted by RobertMe
Yes, *at some point*, but when is that? There will always be people that follow the bleeding edge, but I also know many that have installed XBMC-Live and when it works they don't upgrade or touch it, because it works reliably. IMO Eden will be used in the wild for months, or even years after Frodo is marked stable.
A couple of weeks ago I already spoke with mzanetti about Frodo support and although we didn't really come to a conclusion, at some point we most likely will drop Eden support.
Originally Posted by RobertMe
My fear is that xbmcremote then might be perceived by 'regular users' as unfinished and buggy. Besides, the moment Frodo's RPC API stops being backwards compatible, xbmcremote will degrade even more for Eden users.
So there will be no "degraded" version for Eden users. Although I guess they would still be able to use a new Frodo based version, but that would mean they have some buttons and things which wouldn't work (non working keyboard and some buttons on the gesturepad not working would be most notable I guess).
On the other hand, not including support for Frodo's new features for a long time is also unwanted of course.
One solution could be to have 2 versions of xbmcremote in the repositories (hence having the 2 branches I mentioned before), but runtime detection is IMO very possible, and by internally using a simple API abstraction layer/delegate this should extend into Frodo+1 as well..
| The Following User Says Thank You to accumulator For This Useful Post: | ||
|
|
2012-07-26
, 11:34
|
|
Posts: 59 |
Thanked: 168 times |
Joined on Jun 2012
|
#244
|
Very high IMHO value. If a user is using Eden months after Frodo is released he should also just stick to the old Eden compatible remote. And I also don't think there won't be any new features which are still compatible with Eden.
I think it may be possible to make some of the API differences compatible with both versions (most buttons on the keypad are just a single line of code, both for Eden and Frodo). But at least I don't want to clutter the UI code with "if it is Frodo, than display this extra button" code. If it are only a few extra lines of code in the C++ code I will add them. But if both for Eden and Frodo it requires more then, say 10, 20 lines of code, I probably aren't gonna make the change for both versions.
And about the "when to break Eden compatibility?". When we had the discussion a couple of weeks ago mzanetti said he was thinking about "the next version" (after the version we are currently working on) I think. But I also think that would be to soon (as I guess that would still be before the end of the year, when Frodo isn't even final). I would at least like to have a full Eden compatible version till Frodo gets released, without for examples buttons only working in Frodo. Although there may be some nice extras for Frodo users (automatically open keyboard, for one). But these changes shouldn't hinder the Eden users.
I think it may be possible to make some of the API differences compatible with both versions (most buttons on the keypad are just a single line of code, both for Eden and Frodo). But at least I don't want to clutter the UI code with "if it is Frodo, than display this extra button" code. If it are only a few extra lines of code in the C++ code I will add them. But if both for Eden and Frodo it requires more then, say 10, 20 lines of code, I probably aren't gonna make the change for both versions.
And about the "when to break Eden compatibility?". When we had the discussion a couple of weeks ago mzanetti said he was thinking about "the next version" (after the version we are currently working on) I think. But I also think that would be to soon (as I guess that would still be before the end of the year, when Frodo isn't even final). I would at least like to have a full Eden compatible version till Frodo gets released, without for examples buttons only working in Frodo. Although there may be some nice extras for Frodo users (automatically open keyboard, for one). But these changes shouldn't hinder the Eden users.
|
|
2012-07-27
, 10:04
|
|
Posts: 49 |
Thanked: 103 times |
Joined on Apr 2010
|
#245
|
Originally Posted by RobertMe
For most that is easier said than done. How would users downgrade after they get the Frodo version through the updates?
If a user is using Eden months after Frodo is released he should also just stick to the old Eden compatible remote.
But yeah, it is of course a possibility, if there will be two packages (hence my suggestion for 2 stable branches)..
Originally Posted by RobertMe
I guess most can be done through a variable binding on the visible QML property.
And I also don't think there won't be any new features which are still compatible with Eden.
I think it may be possible to make some of the API differences compatible with both versions (most buttons on the keypad are just a single line of code, both for Eden and Frodo). But at least I don't want to clutter the UI code with "if it is Frodo, than display this extra button" code. If it are only a few extra lines of code in the C++ code I will add them. But if both for Eden and Frodo it requires more then, say 10, 20 lines of code, I probably aren't gonna make the change for both versions.
Originally Posted by RobertMe
Yes it's hard to say. I guess breaking Eden compatibility happens when it's too much work to maintain the difference in 1 codebase. My point is that we should try.
And about the "when to break Eden compatibility?". When we had the discussion a couple of weeks ago mzanetti said he was thinking about "the next version" (after the version we are currently working on) I think. But I also think that would be to soon (as I guess that would still be before the end of the year, when Frodo isn't even final). I would at least like to have a full Eden compatible version till Frodo gets released, without for examples buttons only working in Frodo. Although there may be some nice extras for Frodo users (automatically open keyboard, for one). But these changes shouldn't hinder the Eden users.
But actions are louder than words, so maybe I should invest some time and help out coding
 |
|
2012-07-27
, 12:34
|
|
Posts: 149 |
Thanked: 72 times |
Joined on Mar 2012
@ Istanbul,Turkey
|
#246
|
I want to help you on Turkish translation.More language , more usable software 
|
|
2012-07-27
, 16:57
|
|
Posts: 59 |
Thanked: 168 times |
Joined on Jun 2012
|
#247
|
IMHO two separate packages/versions aren't going to happen. When we're going to support Frodo (and possibly break Eden), normal users should still be able to just update (Software Update notification). Two different branches would also be a burden to maintain, so the Eden one wouldn't be developed anymore. The only sensible solution would be to rebrand the latest Eden compatible version to "xbmcremote-legacy" or something along those lines, and it probably wouldn't be maintained anymore afterwards.
The "visible" QML property also isn't an ideal solution. As the elements are still in the QML and it's sometimes screwed up. For example in the homescreen (music, videos, pictures) long press music or video, notice how the first item ("Show files") has a rounded corner, and click it. Then you long press the item again, and notice the "Show library" item (which is now the first one), it doesn't have the rounded corners. This is due to the first item, "Show files", being invisible, but QML still recognizing it as the first item and thus giving it the rounded corners (instead of giving the first visible item the rounded corners). When adding more and more (in)visible switches I think it would also add more of these minor glitches.
And in case you want to contribute, just join #xbmcremote on Freenode (it's hidden so you need to enter the name manually and can't search it). I'm mostly there between 4PM and 8PM UTC (which is 6PM till 10PM in western europe timezone). Don't really know about mzanetti as he has some kind of server which keeps him logged on.
The "visible" QML property also isn't an ideal solution. As the elements are still in the QML and it's sometimes screwed up. For example in the homescreen (music, videos, pictures) long press music or video, notice how the first item ("Show files") has a rounded corner, and click it. Then you long press the item again, and notice the "Show library" item (which is now the first one), it doesn't have the rounded corners. This is due to the first item, "Show files", being invisible, but QML still recognizing it as the first item and thus giving it the rounded corners (instead of giving the first visible item the rounded corners). When adding more and more (in)visible switches I think it would also add more of these minor glitches.
And in case you want to contribute, just join #xbmcremote on Freenode (it's hidden so you need to enter the name manually and can't search it). I'm mostly there between 4PM and 8PM UTC (which is 6PM till 10PM in western europe timezone). Don't really know about mzanetti as he has some kind of server which keeps him logged on.
Originally Posted by trayhoper
I think you're best of asking mzanetti about it. But in case you're already familiar with Qt development you may download the source code from gitorious and run lupdate to generate a xbmcremote_tr.ts file (I guess it would be tr for Turkish) in the i18n folder. When you've got this file generated you can use Qt Linguist to fill in all the translations and you can send the file to mzanetti afterwards (using a merge request on gitorious, and I guess you could also send him an email to the address which is listed in the about screen of the app).
I want to help you on Turkish translation.More language , more usable software
|
|
2012-07-27
, 17:53
|
|
Posts: 203 |
Thanked: 375 times |
Joined on Nov 2009
|
#248
|
Hi,
there's no need to speculate about the future releasing... First of all, Xbmcremotes git master is still 100% compatible to Eden and there is no feature in the queue yet that would change that. Sure, at some point it might happen but then I'll release a last Eden-only version to the store and the new incompatible ones through another download until Frodo is out. But at that point most of the new features will be for Frodo only so you won't miss much on Eden.
there's no need to speculate about the future releasing... First of all, Xbmcremotes git master is still 100% compatible to Eden and there is no feature in the queue yet that would change that. Sure, at some point it might happen but then I'll release a last Eden-only version to the store and the new incompatible ones through another download until Frodo is out. But at that point most of the new features will be for Frodo only so you won't miss much on Eden.
|
|
2012-07-27
, 18:56
|
|
Posts: 203 |
Thanked: 375 times |
Joined on Nov 2009
|
#249
|
Originally Posted by trayhoper
Hi, please contact me via email so I can send you the latest translation files and release candidate packages. You can find my mail address in the about dialog of Xbmcremote. If you feel comfortable with it, feel free to join #xbmcremote on freenode as RobertMe already pointed out. We are happy to help you getting started if you never did translations before.
I want to help you on Turkish translation.More language , more usable software
|
|
2012-08-19
, 18:53
|
|
Posts: 149 |
Thanked: 57 times |
Joined on Dec 2009
|
#250
|
Hi
Just wanted to report a small bug that happened to me.
The pause video/audio if incoming call enters is great, but If I'm watching something and pause before the call comes in, after the call, the remote resumes playback. IMHO this should be done only if the pausing was caused by an incoming call, not if the user does so. I hope it's easy to fix.
Also, when can we expect a new release?
Thanks,
Just wanted to report a small bug that happened to me.
The pause video/audio if incoming call enters is great, but If I'm watching something and pause before the call comes in, after the call, the remote resumes playback. IMHO this should be done only if the pausing was caused by an incoming call, not if the user does so. I hope it's easy to fix.
Also, when can we expect a new release?
Thanks,