Dear x2go users,
for the last months we've been working on a new release. First we thought to bring some new features, but now we'll bundle it, because there where many changes needed. It still will take some time to the release, but we wan't to inform you on some changes we are discussing. First of all: We are planing a multi session x2goclient for the release after the next release. So there will be a lot of work of redesigning our clients. This would be easier with only one client architecture and as the Qt client is our base for the Linux, Windows, Maemo and Mac OSX platforms, we are asking the question:
Would it be ok to focus our work on the Qt client and to stop/reduce our work on the GTK client?
If we would go on developing both clients equally, it will really take a long time to implement all new planned features and this will slow down the whole project. The Question can also be transformed: Is there anybody interested to help us to keep the GTK client up to date?
Please tell us your thoughts but keep in mind, that the Qt Toolkit is available on all major distros and we'll keep on developing our Gnome bindings. This will not be a preconfigured "choice of Desktop Environment".
So we think we should now continue with some of the new features of the next release (as a contrast):
Yes, there will be a Browser Plugin. It will be realized as a "sponsored development" so we'll get some money for our work and the sponsor will be named. You'll be able to integrate the plugin into a Website and you'll have all features of the x2goclient.
Yes there will be a "session sharing" option without the need of a LDAP server. The new "session sharing" option will make it possible to share a x2go session with another user, to share a already started xorg session with another user and to share a session with more than one user. There will be a system tray application which will help configuring the sharing settings.
After getting so many mails about a wiki for documentation - yes we are working on a wiki which will replace the odf/pdf/html manuals.
We are looking for new localisations. If x2goclient is not available in your language and you want to translate it, please let us know (on the list ). We'll provide a *.ts file for your language (qt-linguist).
We'll announce the the release here on the list and on our blog - at the moment we can't tell you when it'll be ready. So please stay tuned and tell us what you think about the news...
best regards,
Heinz and Alex
Would it be ok to focus our work on the Qt client and to stop/reduce our work on the GTK client? Thanks for asking. I would think as long as we do not require any of
On Sat, 2010-02-20 at 22:32 +0100, Heinz-M. Graesing wrote: <snip> the KDE libraries, i.e., it is true standalone Qt, there is no problem discontinuing GTK. The portability seems to be the whole point of Qt.
However, will you maintain the CLI client? We have found that handy for troubleshooting and can think of some other useful applications for it.
<snip> Yes, there will be a Browser Plugin. It will be realized as a "sponsored development" so we'll get some money for our work and the sponsor will be named. You'll be able to integrate the plugin into a Website and you'll have all features of the x2goclient.
Fabulous and many, many thanks to the sponsor. <snip>
Heinz-M. Graesing píše v So 20. 02. 2010 v 22:32 +0100:
Yes there will be a "session sharing" option without the need of a LDAP server. The new "session sharing" option will make it possible to share a x2go session with another user, to share a already started xorg session with another user and to share a session with more than one user. There will be a system tray application which will help configuring the sharing settings.
Great!
We are looking for new localisations. If x2goclient is not available in your language and you want to translate it, please let us know (on the list ). We'll provide a *.ts file for your language (qt-linguist).
I would take care about the Czech translation.
P.S. If possible, please keep in mind to make the MS Windows client "portable" - i.e. to install/run it without admin rights.
Regards,
Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only)
On Sat, 20 Feb 2010, Heinz-M. Graesing wrote:
for the last months we've been working on a new release. First we thought to bring some new features, but now we'll bundle it, because there where many changes needed.
It still will take some time to the release, but we wan't to inform you on some changes we are discussing.
hmmm --- so the roadmap is non-public, or not being developed in the open? Doesn't this imply that this is not:
What is x2go?
x2go is an open source terminal server project
but rather a commerical project, that permits non-insider people to watch it develop in the open, under a non-encumbering license?
I am not trying to be argumentative here, but to have a internal roadmap that is not comminucated in its development or implementation seems to imply a problem in project design
First of all: We are planing a multi session x2goclient for the release after the next release. So there will be a lot of work of redesigning our clients. This would be easier with only one client architecture and as the Qt client is our base for the Linux, Windows, Maemo and Mac OSX platforms, we are asking the question:
Would it be ok to focus our work on the Qt client and to stop/reduce our work on the GTK client?
The counter-view, is that if it is difficult at the presentation layer to adapt to multiple widget sets, this probably means that the API boundries are not well defined, and need rethinking.
A customary three-tier model usually has a presentation front end, a application logic layer in the middle, and a data store in the back. There are well defined boundries at each interface point, so that one can substitute (and add capacity, facility for failover, and fanout) at the needed point independent of afecting the other two.
The weblog poll asks:
Can a terminal server be part of "desktop virtualization" or will there only be virtual machines for every user?
and I suspect I am the only vote for 'No, (other reason)' where the 'other reason' I have in mind is that a administration console should be just anohter instance, albeit with specifl rights, AND, that the reason: 'Yes, because it will help administring huge amounts of users!' implies pretty clearly that Command Line API, and 'curl' and related 'web-like tools support (fr automated provisioning and management [or even leveraging the present LDAP backend into something like GOSA is not being considered]
If we would go on developing both clients equally, it will really take a long time to implement all new planned features and this will slow down the whole project. The Question can also be transformed: Is there anybody interested to help us to keep the GTK client up to date?
Please tell us your thoughts but keep in mind, that the Qt Toolkit is available on all major distros and we'll keep on developing our Gnome bindings. This will not be a preconfigured "choice of Desktop Environment".
The competition between the two FOSS modern widget tool kits, is that this pretends that, say, Tk/Tcl, OpenMotif, or wxWindows do not exist, and that one HAS to choose to stay with the latest bleeding edge 'coolness' to access some 'latest new feature'. That alone is a clear warning sign of API boundry bleed-over, and over-tight integration to one implementation mothodology
So we think we should now continue with some of the new features of the next release (as a contrast):
Yes, there will be a Browser Plugin. It will be realized as a "sponsored development" so we'll get some money for our work and the sponsor will be named.
You'll be able to integrate the plugin into a Website and you'll have all features of the x2goclient.
but part of implementing this is clearly solving a design of a webbish API to do the GETS, POST, and PUTS, possibly with 'REST' and Web 2.0 hotness. If web control actions cannot be specified into a series of atomic actions of this sort, one runs the risk of accidentially designing an API model where some state is preserved at the client, rather than only at the servers
Yes there will be a "session sharing" option without the need of a LDAP server.
I guess I am confused here - how is a LDAP server on 127.0.0.1 harder to get going that hte pgSQL database. If the complaint is 'it is too hard to set up, this is a symptom of: write a better setup and diagnostic wizard , rather than: remove the facility
What am I missing here?
The new "session sharing" option will make it possible to share a x2go session with another user, to share a already started xorg session with another user and to share a session with more than one user. There will be a system tray application which will help configuring the sharing settings.
After getting so many mails about a wiki for documentation - yes we are working on a wiki which will replace the odf/pdf/html manuals.
but how does one credibly version here -- the problem with wiki's is that the end up with locked pages for some to edit, and open pages that gather spam, som one cannot simply print the 'pdf' that a wiki might offer to produce of an entire site.
.. and what is wrong with documentation tools like the older TeX / LaTeX, or the later DocBook, which are designed for version control system friendly collaborative editting? I think a wiki is the wrong way to go for ystem documenation deliverables [having fought this battle and lost in my work with CentOS]
We are looking for new localisations. If x2goclient is not available in your language and you want to translate it, please let us know (on the list ). We'll provide a *.ts file for your language (qt-linguist).
and again, this is a 'one tool kit' specific solution, rather than the FSF .po file approach which is generic.
We'll announce the the release here on the list and on our blog - at the moment we can't tell you when it'll be ready. So please stay tuned and tell us what you think about the news...
;)
-- Russ herrold
Hello,
R P Herrold schrieb:
hmmm --- so the roadmap is non-public, or not being developed in the open? Doesn't this imply that this is not:
What is x2go?
x2go is an open source terminal server project
but rather a commerical project, that permits non-insider people to watch it develop in the open, under a non-encumbering license?
Ok - x2go is open and with the previous mail, I've informed you about the latest development. Of cause there are a lot more possibilities to do this and to do it more open. I'm sorry that this was not made - but we are are very small team and x2go is still an sparetime project. We've received a lot of whishes and ideas with the help of our webform - which previous mail 8 people have answered using the webform. As there will be
a git reposity and a wiki in future, we should add an wishlist. But what we really don't like is, when the communication/information about our project gets fragmented. Thank you for your open words!
A customary three-tier model usually has a presentation front end, a application logic layer in the middle, and a data store in the back.
There are well defined boundries at each interface point, so that one can substitute (and add capacity, facility for failover, and fanout) at the needed point independent of afecting the other two.
As you might have recordnized, there is already a wrapper for database storage, so it is no problem to realize support for other databases. The fact, that we've not released a new graphical administration set yet, is due to a discussion on exacctly this topic. A popular discussed idea is building an JSON api for all administration functionalities. So anybody can build a administration gui or automatism even over the web and not in the same lan. This would solve the problem, that anybody has other ideas about what a administration gui should do. On the other side this really means a lot of work and can't be done with the existing release. So again this is part of the question: what is really needed?
The competition between the two FOSS modern widget tool kits, is that this pretends that, say, Tk/Tcl, OpenMotif, or wxWindows do not exist, and that one HAS to choose to stay with the latest bleeding edge 'coolness' to access some 'latest new feature'. That alone is a clear warning sign of API boundry bleed-over, and over-tight integration to one implementation mothodology
Qt is a bit more that only a widget set and it is a great help because of so many "ready to use" capabilities. Sure - we too are looking on what Nokia will do with Qt, but at the moment it is - in our eyes - the best way to develop software for a lot of platforms. Qt is used for the Client, which really should be running on as many platforms as possible.
You'll be able to integrate the plugin into a Website and you'll have all features of the x2goclient.
but part of implementing this is clearly solving a design of a webbish API to do the GETS, POST, and PUTS, possibly with 'REST' and Web 2.0 hotness. If web control actions cannot be specified into a series of atomic actions of this sort, one runs the risk of accidentially designing an API model where some state is preserved at the client, rather than only at the servers
The x2goplugin will be a plugin like "acroread" or the "flashplugin". In fact it will be a x2goclient shown in a <object></object> tag with the known communication protocols. You'll still have to contact a sshd server - so preconfigured it will use the port 22.
Yes there will be a "session sharing" option without the need of a LDAP server.
I guess I am confused here - how is a LDAP server on 127.0.0.1 harder to get going that hte pgSQL database. If the complaint is 'it is too hard to set up, this is a symptom of: write a better setup and diagnostic wizard , rather than: remove the facility
What am I missing here?
In the actual release, the session shadowing was only available over x11vnc and as an option in our LDAP administration gui. The new session shadowing is nx native and now available on every installation. The first one could also be realized by yourself.
.. and what is wrong with documentation tools like the older TeX / LaTeX, or the later DocBook, which are designed for version control system friendly collaborative editting? I think a wiki is the wrong way to go for ystem documenation deliverables [having fought this battle and lost in my work with CentOS]
Again this was a wish by actual 56 persons - their idea was, that this would be better accessed by the search engines and that the hpertext would solve the problem of getting to long documentations. Again : Yes it would help, if I could go back in time and to change all this dialogs to the mailing list, so they would have been discussed more open...
We are looking for new localisations. If x2goclient is not available in your language and you want to translate it, please let us know (on the list ). We'll provide a *.ts file for your language (qt-linguist).
and again, this is a 'one tool kit' specific solution, rather than the FSF .po file approach which is generic. Yes - I've never understood why they have to do this on their own...
Ok - dear x2go community - please understand that we are a small Team and that sometimes there is a bit of attractive laziness and we prefer to work on the code instead on communications. We'll try to relay all future input visibly open.
Thank you for your open words,
Heinz
Dear Heinz,
thank you for taking the time to inform the community and to answer Russ’s post.
Am Sonntag, den 21.02.2010, 12:29 +0100 schrieb Heinz-M. Graesing:
R P Herrold schrieb:
[…]
We'll try to change that in furture, but we're still getting a lot of complaints only to offer a "mailing list". Even on this important previous mail 8 people have answered using the webform. As there will be a git reposity and a wiki in future, we should add an wishlist. But what we really don't like is, when the communication/information about our project gets fragmented. Thank you for your open words!
[…]
.. and what is wrong with documentation tools like the older TeX / LaTeX, or the later DocBook, which are designed for version control system friendly collaborative editting? I think a wiki is the wrong way to go for ystem documenation deliverables [having fought this battle and lost in my work with CentOS]
Again this was a wish by actual 56 persons - their idea was, that this would be better accessed by the search engines and that the hpertext would solve the problem of getting to long documentations. Again : Yes it would help, if I could go back in time and to change all this dialogs to the mailing list, so they would have been discussed more open...
Because you wrote you will use Git in the future I suggest to take a look at ikiwiki [1].
The great advantage for you is, that if you implement a new feature or change something which needs to be documented, you can do it in the same repository without opening a browser, logging in and updating the respective Wiki page using the Web form.
Because it is so easy for developers to update the documentation, the hope is that the documentation stays up to date.
Of course people can still use the Web interface to change ikiwiki.
I hope I did not start a flame war now about what wiki to use.
But I recommend before you choose a solution to think about your needs and what you will be able to cope with having for example time constraints and then choose something fitting your needs.
Thanks again to you and your team for your great work,
Paul
On Sun, 2010-02-21 at 12:29 +0100, Heinz-M. Graesing wrote: <snip>
Ok - dear x2go community - please understand that we are a small Team and that sometimes there is a bit of attractive laziness and we prefer to work on the code instead on communications. We'll try to relay all future input visibly open.
Thank you for your open words, <snip> Entirely understood and appreciated, Heinz. I, and I'm sure many others, are deeply grateful that you have done so much great work on a spare-time project.
I think Russ brings an invaluable perspective from a very mature and large project and his suggestions will be great to implement with the patience and understanding that it will take time and additional resources.
I might comment that, although a wiki may present the problems Russ enumerates, it will also make contributing more accessible to those who are not familiar with tools that have been mainstay for developers for years. There may be a number of administration/implementation type folks who can contribute valuable documentation who do not have the time to learn LaTex or Docbook.
Thanks for all you and Oleksandr have done - John
Heinz-M. Graesing schreef:
Dear x2go users,
for the last months we've been working on a new release. First we thought to bring some new features, but now we'll bundle it, because there where many changes needed. It still will take some time to the release, but we wan't to inform you on some changes we are discussing. First of all: We are planing a multi session x2goclient for the release after the next release. So there will be a lot of work of redesigning our clients. This would be easier with only one client architecture and as the Qt client is our base for the Linux, Windows, Maemo and Mac OSX platforms, we are asking the question:
Would it be ok to focus our work on the Qt client and to stop/reduce our work on the GTK client?
Yes. I understand it's much work to work on two clients.
( But for the longer future I would advice to take a look at WxWidgeds. When you use that, you don't need to add a toolkit, because the original toolkit of the platform is used. )
Yes, there will be a Browser Plugin. It will be realized as a "sponsored development" so we'll get some money for our work and the sponsor will be named. You'll be able to integrate the plugin into a Website and you'll have all features of the x2goclient.
Nice to hear!
Yes there will be a "session sharing" option without the need of a LDAP server. The new "session sharing" option will make it possible to share a x2go session with another user, to share a already started xorg session with another user and to share a session with more than one user. There will be a system tray application which will help configuring the sharing settings.
Really great ;-)
After getting so many mails about a wiki for documentation - yes we are working on a wiki which will replace the odf/pdf/html manuals.
We are looking for new localisations. If x2goclient is not available in your language and you want to translate it, please let us know (on the list ). We'll provide a *.ts file for your language (qt-linguist).
I did this already for the Dutch language. The Dutch translation is in the GTK version, but not in the QT version. Are there problems with the translation?
We'll announce the the release here on the list and on our blog - at the moment we can't tell you when it'll be ready. So please stay tuned and tell us what you think about the news...
Success with the good work...
Met vriendelijke groet, Paul van der Vlis.
Heinz-M. Graesing <x2go-dev@...> writes:
We are looking for new localisations. If x2goclient is not available in your language and you want to translate it, please let us know (on the list ). We'll provide a *.ts file for your language (qt-linguist).
Hi, my name's Vincenzo Reale and I'm a member of the KDE Italian translation team. I'm interested in translating x2goclient in Italian. Is there someone already working on it?
Thanks in advance, Vincenzo