Quickly: Rychlý a snadný vývoj programů v Ubuntu

Quickly je sada nástrojů, které Canonical připravil pro usnadnění a zrychlení vývoje aplikací v Ubuntu. Více (včetně příkladu) také v článku na Ars Technica.

26.8.2009 10:23 | Robert Krátký | Zajímavý software

Komentáře

[Non_E]

Je to jen pro py-gtk.

[Espinosa]

Proč je tam tak specificky určeno "rapid development to Ubuntu"? Že vznik inicioval (zaplatil?) Ubuntu a hostí ho na LauchPadu z toho ještě nedělá nástroj pro vývoj aplikací v Ubuntu. S píš v linuxu ne? Dost možná se jedná o multiplatformí nástroj, protože hádám je to celé napsané v Pythonu, takže ani Windows nejsou ze hry.

Pokud z toho článku odstraníme informační hlušinu (tak půlka textu) vyjde z toho že jde o jednoduchý nástroj pro generování šablon pro Python-PythonGtk aplikace s volitelnou (?) integrací pro LaunchPad, Bazaar a Gedite jako editorem. Byla naznačena možnost rozšíření i na další jazyky (?) a nástroje mimo bazaar a launchpad. Jak někdo v diskusi poznamenal obdob Django ale pro desktop a ne web. Je to obdoba appfuse (Java) a Ruby on Rails.

Nenarazil jsem tam na nic specificky Ubuntího kromě tvrzení "tailored to the Ubuntu ecosystem" - bez jakéhokoliv zpřesnění. Hádám další prázdná fráze.

 

[l4m4]

Nejspíš proto, že Ubuntu je jediný operační systém, který má budoucnost, takže zmiňovat cokoli jiného je irelevantní.

[Michal Vyskočil]

[Espinosa]

Lol, třeba už založili Ubuntu-kvizici proti rouhačům a nepravověrcům co pochybují že Ubuntu je operační systém a tvrdí že je to distribuce jako každá jiná

 

[...............23]

Mne to teda podľa toho článku pripadá ako riadna zbytočnosť. O také veci by sa snáď malo starať IDE, a nie nejaký command-line tool...

[l4m4]

Proč by mělo každé IDE implementovat tyto funcke znovu? Syndrom NIH?

[...............23]

Práveže veľa ich tie funkcie nemá zabudované v sebe, ale používa externé nástroje (autotools, cmake, qmake, git, svn, qt designer...)

[l4m4]

Však nástroj typu quickly tyhle věci nenahrazuje. Nahrazuje ovšem vygenerování projektu podle šabolny a podobné funkce, které každé IDE implementuje po svém.

[...............23]

A práve preto nechápem načo je to dobré. Imho človek buď chce mať spravované také veci pohodlne automaticky a použije IDE, alebo si to chce riešiť po svojom a spravuje si projekt ručne.

Ten úvodný odstavec ktorý majú vo wiki je hovadina akú som už dlho nečítal:

Given the richness and variety of the Linux platform, programming on Linux should be easy and fun. However, it's not easy and fun because it is too hard to learn. It is too hard to learn because there are too many choices, and too much information to wade through.

So adding another choice will make it simpler, right? Preferably one that you have to learn to use first...

[l4m4]

Chci mít věci spravované pohodlně, nechci používat IDE, nevidím v tom rozpor a nestydím se za to ;)

Nevím, zda bych použil takovouto věc, ale možná proč ne. Nakonec člověk používá třeba libtoolize, které potřebuje automake, který potřebuje autoconf, ..., takže prostě přibude další vrstva.

[Jiri Bajer]

Pokud jsem dobre pochopil to uvodni oznameni, obsahuje Quickly sablony, kteryma se da priohnout tak, aby nezavisel na nicem, co pochazi z Ubuntu/od Canonicalu.

I tak je to ale podle me nastroj k nicemu, mnohem uzitecnejsi by bylo konecne dotahnout patch na pridani code foldingu do geditu, konsolidovat dokumentaci k PyGTK (tutorial, FAQ, reference, examples, nahrada ukazek s libglade pomoci gtkbuilderu apod.) a popularizovat. Generovani sablon je iMHO pitomost, Python a PyGTK jsou fajn prave tim, ze minimalizuji mnozstvi boilerplate kodu (rozdil oproti C+GTK je dost vyraznej) a umoznuji soustredit se na vyvijenou funkcnost. V Glade si zbytecnost generovani sablon uvedomili uz davno a prestali tuhle (nepouzivanou) funkcnost poskytovat.

Sam jsem pred pul rokem zacal v PyGTK psat a i kdyz si obcas rvu vlasy z toho, jak GTK se svym pseudoobjektovym pristupem obcas vykoukne na povrch a zbytecne przni jinak neuveritelne elegantni Python, povazuju PyGTK za zabavnej, elegantni a snadnej nastroj k psani desktopovych aplikaci (nenarocnych na vypocetni vykon). Psat to v C bych nemohl - gobject system je desive neprehlednej (dliuhy identifikatory, spousta argumentu metod navic jen kvuli reseni typu dat, diky absenci iteratoru, listu a tuplu vsechno dlouho trva nabusit do kodu - fujble).

Pokud ma nekdo zajem o spolupraci pri dokumentaci a popularizaci PyGTK, dejte vedet. Snazim se prispivat do oficialniho FAQ (konkretne posledni zaznamy u TreeView/TreeModel), ale porad jsem jeste ve stadiu objevovani triku (napriklad vyrobit pohled na stromova data tak, aby se tvarily jako plocha tabulka a daly se filtrovat a tridit je docela maso).