Hello,
as we are now on the road to the release I want to focus to more advanced pdf export.
The goal is to have a press ready output. With more detailed font, colour and page handling. As I understand our cairo renderer can output pdf but will never achieve this goal bcs cairo is simply not made for this. (Colour handling). So this task will end up with code taken from scribus or gegl or something. as starting point for reviewing the features I collected screenshots from scribus and corel export dialogues here http://wiki.inkscape.org/wiki/index.php/Export_To_Pdf_dialogs However the converter will look like the export dialogue should be kept simple for regular users and more detailled for the experts. .... If we can share some force into this topic over the next period would be perfect.
Also did we talk about "save vs export vs save copy as"? I would see Inkscape "open and save" svg only and the other formats just "import and export". Any thoughts?
Regards,
Adib. --
18 февр. 2015 г. 3:41 пользователь "the Adib" <theadib@...400...> написал:
As I understand our cairo renderer can output pdf but will never achieve
this goal bcs cairo is simply not made for this. (Colour handling). So this task will end up with code taken from scribus or gegl or something.
That would be the "or something" option :)
Libpdf from Scribus heavily depends on its DOM.
GEGL has no code to write color-separated PDFs, although it would be nice to have it there.
Also did we talk about "save vs export vs save copy as"? I would see Inkscape "open and save" svg only and the other formats just
"import and export".
+1
Alex
On Wed, 2015-02-18 at 00:41 +0100, the Adib wrote:
Also did we talk about "save vs export vs save copy as"?
I would see Inkscape "open and save" svg only and the other formats just "import and export".
Any thoughts?
This makes slightly more sense in inkscape than it did in gimp, (simply because svg is going to be the primary format usable outside of the program, where as gimp's format is a cul-de-sac)
The better arrangement is to allow save to redirect to a conversion for an opened file, but not for a new document. I open a pdf, maybe I want to save the pdf back (although maybe not as our fidelity is poor)
This get's more interesting when one opens and saves png files back as it modifies the image layer in the opened document. :-)
Martin,
2015-02-18 3:45 GMT+01:00 Martin Owens <doctormo@...400...>:
On Wed, 2015-02-18 at 00:41 +0100, the Adib wrote:
Also did we talk about "save vs export vs save copy as"?
I would see Inkscape "open and save" svg only and the other formats just "import and export".
Any thoughts?
+1
-- Christoffer Holmstedt
Also did we talk about "save vs export vs save copy as"? I would see Inkscape "open and save" svg only and the other formats just "import and export". Any thoughts?
That sounds reasonable, although i am (from a user standpoint) always uncertain if an "Import" opens the file in a new document or inserts it into the existing one. i would expect the latter one, but i have seen programs doing the opposite.
maybe this can be clarified with better wording.
regards, TimeWaster
Regards,
Adib.
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.cl...
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 18 February 2015 at 10:17, TimeWaster <sebi@...2963...> wrote:
Also did we talk about "save vs export vs save copy as"? I would see Inkscape "open and save" svg only and the other formats just "import and export". Any thoughts?
That sounds reasonable, although i am (from a user standpoint) always uncertain if an "Import" opens the file in a new document or inserts it into the existing one. i would expect the latter one, but i have seen programs doing the opposite.
Inkscape already adds the files to the existing document and I agree that this is the expected behavior of 'Import'. Also letting 'Open...' open the file into a new document is totally fine.
Regarding the discussion about 'save vs. export vs. saving a copy: I believe it is ok that 'Save' covers all formats. Though saving into a pixel format like PNG doesn't make much sense, IMO, when you don't get options presented for how to save it like within the 'Export to PNG Image' dialog. This also applies to file formats, which can't losslessly save the current document, offer special format features or treatment of the document's information like the mentioned PDF export. In those cases the user should be able to adjust the format's options within the 'Save As...' dialog.
'Save a Copy...' seems unnecessary to me, because it looks like it does the same as 'Save As...'. So it should be removed. Or does it do something different than 'Save As...'?
One annoying thing in regard of 'Save' is that it can't distinguish between standard SVG files and Inkscape flavored SVGs. When a plain SVG file is opened, edited and then saved via 'Save', the file is always saved as Inkscape SVG.
Also it is not possible (or I missed the option) to define the default format a document is saved to. Though that may go beyond this discussion. Please let me know if I should file an issue for that.
Sebastian
Sebastian Zartner wrote
On 18 February 2015 at 10:17, TimeWaster <
sebi@
> wrote:
'Save a Copy...' seems unnecessary to me, because it looks like it does the same as 'Save As...'. So it should be removed. Or does it do something different than 'Save As...'?
I use the "Save a Copy..." function a lot and I find it extremely useful. Its difference from "Save As..." is that with the latter the current file becomes the last saved. This means that if you open "MyFile.svg", work on it and then "Save As..." as "NewFile.svg", from now on you are working on "NewFile.svg" not on the former that you opened. This might be exactly what you want, but it could not be either if you intended to make a snapshot of your situation and continue working on the original file. This difference becomes important when you save the current file in a different format, e.g. in PDF: if you "Save As..." in PDF then upon closing Inkscape you'll get a warning that you have saved the file in a lossy format and if you don't "Save As..." it again in SVG (!) you're going to lose your work. While, if you "Save a Copy..." in PDF, upon closing the file you'll be asked to save your work directly in the original SVG file.
-- View this message in context: http://inkscape.13.x6.nabble.com/Inkscape-the-next-release-tp4972838p4973005... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
On 2-3-2015 12:03, LucaDC wrote:
Sebastian Zartner wrote
'Save a Copy...' seems unnecessary to me, because it looks like it does the same as 'Save As...'. So it should be removed. Or does it do something different than 'Save As...'?
I use the "Save a Copy..." function a lot and I find it extremely useful.
I hear this all the time.
Its difference from "Save As..." is that with the latter the current file becomes the last saved. This means that if you open "MyFile.svg", work on it and then "Save As..." as "NewFile.svg", from now on you are working on "NewFile.svg" not on the former that you opened. This might be exactly what you want, but it could not be either if you intended to make a snapshot of your situation and continue working on the original file. This difference becomes important when you save the current file in a different format, e.g. in PDF
Or when saving a 'backup' of your work. Save a Copy is different functionality and is separate from a save as/export/import discussion.
The open/save/import/export discussion pops up every now and then, and frankly I do not see much point in it. Apparently there are people that like import/export better, others like just "save as" better. If you feel very strongly about it, go ahead and implement import/export; I think it will not change anybody's experience; just a bit of code duplication and some extra UI buttons.
cheers, Johan
Well, if the discussion pops up every now and then, it must be an issue.
How about following some industry pseudo-standard? How do most software packages handle this?
I am not sure if doing things the blender way (different) is the solution either.
On Tue, Mar 3, 2015 at 2:03 AM, Johan Engelen <jbc.engelen@...2592...> wrote:
On 2-3-2015 12:03, LucaDC wrote:
Sebastian Zartner wrote
'Save a Copy...' seems unnecessary to me, because it looks like it does the same as 'Save As...'. So it should be removed. Or does it do something different than 'Save As...'?
I use the "Save a Copy..." function a lot and I find it extremely useful.
I hear this all the time.
Its difference from "Save As..." is that with the latter the current file becomes the last saved. This means that if you open "MyFile.svg", work on it and then "Save
As..."
as "NewFile.svg", from now on you are working on "NewFile.svg" not on the former that you opened. This might be exactly what you want, but it could not be either if you intended to make a snapshot of your situation and continue working on the original file. This difference becomes important when you save the current file in a different format, e.g. in PDF
Or when saving a 'backup' of your work. Save a Copy is different functionality and is separate from a save as/export/import discussion.
The open/save/import/export discussion pops up every now and then, and frankly I do not see much point in it. Apparently there are people that like import/export better, others like just "save as" better. If you feel very strongly about it, go ahead and implement import/export; I think it will not change anybody's experience; just a bit of code duplication and some extra UI buttons.
cheers, Johan
Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, 2015-03-03 at 05:42 +0700, Bit Barrel wrote:
How about following some industry pseudo-standard? How do most software packages handle this?
Design wise, I'd suggest doing it like this:
https://inkscape.org/en/gallery/item/4754/
It removes the need of a menu that might confuse, but retains the functionality in a more compact way.
We could remember the check position for any more 'Save As' on that file in that session. So people saving as copy a lot won't have an extra step after the first dialog.
Martin,
On 3-3-2015 0:34, Martin Owens wrote:
On Tue, 2015-03-03 at 05:42 +0700, Bit Barrel wrote:
How about following some industry pseudo-standard? How do most software packages handle this?
Like we do currently.
Design wise, I'd suggest doing it like this:
https://inkscape.org/en/gallery/item/4754/
It removes the need of a menu that might confuse, but retains the functionality in a more compact way.
yet with more clicking required and annoyance guaranteed.
-Johan
On Tue, 2015-03-03 at 19:50 +0100, Johan Engelen wrote:
It removes the need of a menu that might confuse, but retains the functionality in a more compact way.
yet with more clicking required and annoyance guaranteed.
Johan this response is very terse and it has been received negatively here.
This desgin increases the clicking by 1 and requires a re-focus. But the design suggestion is only presented to document possible solutions given the degree to which different user's needs interfere.
It's only useful if the menu can be shown to be confusing. And I have no good data to show that it is at this time. A good study might show the opposite is true in practice.
We should get into the habit of asking for and running UX sessions. Maybe something we can do at LGM this year. :-)
Best Regards, Martin Owens
It is funny to see how UI discussion always heat up. The exact same thing happens with Blender. Even though Blender is notorious for its convoluted UI, they categorically refuse to do anything about it and insist it is fine the way it is.
Why not do some real UI research (one way mirror and all that) and let that be the final judge of it?
On Wed, Mar 4, 2015 at 2:25 AM, Martin Owens <doctormo@...400...> wrote:
On Tue, 2015-03-03 at 19:50 +0100, Johan Engelen wrote:
It removes the need of a menu that might confuse, but retains the functionality in a more compact way.
yet with more clicking required and annoyance guaranteed.
Johan this response is very terse and it has been received negatively here.
This desgin increases the clicking by 1 and requires a re-focus. But the design suggestion is only presented to document possible solutions given the degree to which different user's needs interfere.
It's only useful if the menu can be shown to be confusing. And I have no good data to show that it is at this time. A good study might show the opposite is true in practice.
We should get into the habit of asking for and running UX sessions. Maybe something we can do at LGM this year. :-)
Best Regards, Martin Owens
Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Bit,
If you would like to organize and get a thing like this funded, we would welcome such an effort!
Cheers, Josh
On Tue, Mar 3, 2015 at 4:43 PM, Bit Barrel <bitbarrelmedia@...400...> wrote:
It is funny to see how UI discussion always heat up. The exact same thing happens with Blender. Even though Blender is notorious for its convoluted UI, they categorically refuse to do anything about it and insist it is fine the way it is.
Why not do some real UI research (one way mirror and all that) and let that be the final judge of it?
On Wed, Mar 4, 2015 at 2:25 AM, Martin Owens <doctormo@...400...> wrote:
On Tue, 2015-03-03 at 19:50 +0100, Johan Engelen wrote:
It removes the need of a menu that might confuse, but retains the functionality in a more compact way.
yet with more clicking required and annoyance guaranteed.
Johan this response is very terse and it has been received negatively here.
This desgin increases the clicking by 1 and requires a re-focus. But the design suggestion is only presented to document possible solutions given the degree to which different user's needs interfere.
It's only useful if the menu can be shown to be confusing. And I have no good data to show that it is at this time. A good study might show the opposite is true in practice.
We should get into the habit of asking for and running UX sessions. Maybe something we can do at LGM this year. :-)
Best Regards, Martin Owens
Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I would love to (I think this is a really interesting subject) but time constraints unfortunately won't allow for it. But if someone sets up a funding campaign, I'll be the first one to donate!
On Wed, Mar 4, 2015 at 8:50 AM, Josh Andler <scislac@...400...> wrote:
Bit,
If you would like to organize and get a thing like this funded, we would welcome such an effort!
Cheers, Josh
On Tue, Mar 3, 2015 at 4:43 PM, Bit Barrel <bitbarrelmedia@...400...> wrote:
It is funny to see how UI discussion always heat up. The exact same thing happens with Blender. Even though Blender is notorious for its convoluted UI, they categorically refuse to do anything about it and insist it is
fine
the way it is.
Why not do some real UI research (one way mirror and all that) and let
that
be the final judge of it?
On Wed, Mar 4, 2015 at 2:25 AM, Martin Owens <doctormo@...400...> wrote:
On Tue, 2015-03-03 at 19:50 +0100, Johan Engelen wrote:
It removes the need of a menu that might confuse, but retains the functionality in a more compact way.
yet with more clicking required and annoyance guaranteed.
Johan this response is very terse and it has been received negatively here.
This desgin increases the clicking by 1 and requires a re-focus. But the design suggestion is only presented to document possible solutions given the degree to which different user's needs interfere.
It's only useful if the menu can be shown to be confusing. And I have no good data to show that it is at this time. A good study might show the opposite is true in practice.
We should get into the habit of asking for and running UX sessions. Maybe something we can do at LGM this year. :-)
Best Regards, Martin Owens
Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub
for
all things parallel software development, from weekly thought leadership
blogs
to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub
for
all things parallel software development, from weekly thought leadership
blogs
to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 2-3-2015 23:42, Bit Barrel wrote:
Well, if the discussion pops up every now and then, it must be an issue.
(I see no logic in your argument, but here a rant:) In my opinion, it is one of those things that UI "experts" like to "improve", but no-one is actually discontent with the status quo.
-Johan
3 марта 2015 г. 2:43 пользователь "Bit Barrel" <bitbarrelmedia@...400...> написал:
Well, if the discussion pops up every now and then, it must be an issue.
How about following some industry pseudo-standard? How do most software
packages handle this?
Differently.
The rule of thumb is: if you can't save all your project data, either a) limit saving to just internal file format, or b) warn the user every time saving to a "lossy" file format is requested. Both options appear to be annoying to different groups of users.
Alex
Both may be annoying, but one breaks stuff if they don't understand the message (we had a question from a user on fb the other day illustrating that this message wasn't clear to some users still). Still think the option we've gone with is fundamentally the wrong choice. If it isn't svg we shouldn't be doing anything other than importing/exporting it. On 4 Mar 2015 09:46, "Alexandre Prokoudine" <alexandre.prokoudine@...400...> wrote:
3 марта 2015 г. 2:43 пользователь "Bit Barrel" <bitbarrelmedia@...400...> написал:
Well, if the discussion pops up every now and then, it must be an issue.
How about following some industry pseudo-standard? How do most software
packages handle this?
Differently.
The rule of thumb is: if you can't save all your project data, either a) limit saving to just internal file format, or b) warn the user every time saving to a "lossy" file format is requested. Both options appear to be annoying to different groups of users.
Alex
Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
The toughest thing here is I can +1 this all day long because I think it's the right choice, but when I use GIMP, I still go to "Save As" first almost every time. :)
Cheers, Josh
On Wed, Mar 4, 2015 at 2:03 AM, John Cliff <john.cliff@...400...> wrote:
Both may be annoying, but one breaks stuff if they don't understand the message (we had a question from a user on fb the other day illustrating that this message wasn't clear to some users still). Still think the option we've gone with is fundamentally the wrong choice. If it isn't svg we shouldn't be doing anything other than importing/exporting it.
On 4 Mar 2015 09:46, "Alexandre Prokoudine" <alexandre.prokoudine@...972.....> wrote:
3 марта 2015 г. 2:43 пользователь "Bit Barrel" <bitbarrelmedia@...400...> написал:
Well, if the discussion pops up every now and then, it must be an issue.
How about following some industry pseudo-standard? How do most software packages handle this?
Differently.
The rule of thumb is: if you can't save all your project data, either a) limit saving to just internal file format, or b) warn the user every time saving to a "lossy" file format is requested. Both options appear to be annoying to different groups of users.
Alex
Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2015-03-02 20:03 GMT+01:00 Johan Engelen <jbc.engelen@...2592...>:
Or when saving a 'backup' of your work. Save a Copy is different functionality and is separate from a save as/export/import discussion.
I don't think there is a behavioral difference between 'Save a Copy' and 'Export' - for me those are synonyms. The difference between Open and Import is that the former opens a new document and the latter adds the imported content to the current document.
The real problem is that saving / exporting to a raster format is different than saving to a vector format. Raster saving has many more options to specify the area of the export. Yet, I think many people would find it useful to have those options available in vector formats as well. This way there would be no need to distinguish between saving and exporting.
The mockup with the checkbox doesn't seem like a good idea to me - I think it would be prone to errors. The actions 'I want to save my changes' and 'I want to make a new file with this content' are conceptually dissimilar enough to warrant separate menu items.
Regards, Krzysztof
On Wed, 2015-03-04 at 18:51 +0100, Krzysztof Kosiński wrote:
I don't think there is a behavioral difference between 'Save a Copy' and 'Export' - for me those are synonyms. The difference between Open and Import is that the former opens a new document and the latter adds the imported content to the current document.
The real problem is that saving / exporting to a raster format is different than saving to a vector format. Raster saving has many more options to specify the area of the export. Yet, I think many people would find it useful to have those options available in vector formats as well. This way there would be no need to distinguish between saving and exporting.
The mockup with the checkbox doesn't seem like a good idea to me - I think it would be prone to errors. The actions 'I want to save my changes' and 'I want to make a new file with this content' are conceptually dissimilar enough to warrant separate menu items.
I agree completely Krzysztof, I think you have the right idea about how to change the system so it reduces menu items /and/ improves flow. Should we test your design at LGM with other attendees?
Martin,
"If it isn't svg we shouldn't be doing anything other than importing/exporting it." I totally agree.
"The real problem is that saving / exporting to a raster format is different than saving to a vector format. Raster saving has many more options to specify the area of the export." Raster saving might have more options, but why not just show a popup screen if some options are available when saving to anything other than svg? That is how most software packages seem to handle this issue.
I also disagree with how Illustrator and Blender handles this. They also have "Save As", "Save a copy", and "Export". That doesn't mean anything to me if I don't have experience with the software.
This is what I would do: -Ban working on a fileformat which is lossy. That is too risky. Only use inkscape SVG as the working document. This is the only format "Save" would save to. -Don't use "Save a Copy". The functionality is great (I use it all the time), but the terminology sucks. Instead, put this functionality in "Export". But return to the Inkscape SVG working document after saved. -Do not use "Export" And "Save As / Save a Copy" at the same time. They sound too similar and is too confusing. Pick one. I would go with just "Save" (only Inkscape SVG, no save options), and "Export" (anything else, with save options after clicking Export). -Do not put the Export PNG in a different panel which fits in the toolbar. It should be a popup so it is easy to find. The same type of popup which is used for all the other Export file formats. -To improve workflow, offer the ability not to show a popup when exporting a file, but use the settings from Edit-Preferences menu instead.
On Thu, Mar 5, 2015 at 1:09 AM, Martin Owens <doctormo@...400...> wrote:
On Wed, 2015-03-04 at 18:51 +0100, Krzysztof Kosiński wrote:
I don't think there is a behavioral difference between 'Save a Copy' and 'Export' - for me those are synonyms. The difference between Open and Import is that the former opens a new document and the latter adds the imported content to the current document.
The real problem is that saving / exporting to a raster format is different than saving to a vector format. Raster saving has many more options to specify the area of the export. Yet, I think many people would find it useful to have those options available in vector formats as well. This way there would be no need to distinguish between saving and exporting.
The mockup with the checkbox doesn't seem like a good idea to me - I think it would be prone to errors. The actions 'I want to save my changes' and 'I want to make a new file with this content' are conceptually dissimilar enough to warrant separate menu items.
I agree completely Krzysztof, I think you have the right idea about how to change the system so it reduces menu items /and/ improves flow. Should we test your design at LGM with other attendees?
Martin,
Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (12)
-
Alexandre Prokoudine -
Bit Barrel -
Christoffer Holmstedt -
Johan Engelen -
John Cliff -
Josh Andler -
Krzysztof Kosiński -
LucaDC -
Martin Owens -
Sebastian Zartner -
the Adib -
TimeWaster