Sıfırdan bir grafik kitaplığı oluşturma - sayfa 2

 
Алексей Барбашин :

Eminim sıfırdan ve buna değmez.

Çok zeki insanlar aynı standart kütüphaneyi ya da Anadolu kütüphanesini yapmak için çok zaman ve bilgi harcamışlardır.

İnsanlar zaman ve bilgiyi boşa harcadılar ve onu kullanmamak aptallık olur.

Sadece bizim açımızdan her ikisinde de en iyisini alıp yeniyi toplamanız gerekiyor.

Başkalarının hatalarından ders almanız gerekir. Kendimiz yaratacağız :)

Tamamen katılıyorum!

 
Kütüphanenin nihai amacı net değil.
Diğer kitaplıkların hangi eksikliklerini çözmeli veya geliştirmeli? Yoksa temelde yeni bir araç mı olmalı? GUI odaklı mı yoksa kullanıcı grafiği odaklı mı olmalı?
Örneğin, iCanvas kitaplığım, özel grafiklerin kullanılabilirliğini iyileştirmek, kodlama yaparken daha kısa ve daha sezgisel kod, eşzamansız işlevlerin kullanımından kaçınarak çalışma hızını artırmak, fiyata bağlama amacıyla CCanvas kitaplığının mantıksal bir uzantısıydı. -zaman koordinat sistemi ve sadece XY ekran koordinatları değil.
 
Nikolai Semko :
Kütüphanenin nihai hedefi net değil.

Ve bu, nasıl göründüğüm önemli değil, tüm grafik kitaplıkları için ortak bir sorundur.

Forumda önerilen tüm projeler iki sorundan birini çözmelidir: ya kullanıcının gelirini artırın ya da aynı geliri elde etme verimliliğini artırın.

Projenin en az bir yazarının bu görevlerden birinin çözümünü gösteren örnekler gösterme zahmetine girdiğini hatırlamıyorum.

En çarpıcı örnek, "Tuval havalı" konusunda hatırlıyorum - sadece büyüleyici derecede güzel grafikler sunuldu ... ancak, kullanıcının (en azından yazarın) gelirini nasıl artırdığını veya verimliliğini nasıl artırdığını. alıyorum - hala anlamadım .

Aynısı Anatoly'nin kütüphanesidir. Mükemmel yapı, iyi düşünce, ama... Eminim yazarın kendisi bile bu kütüphanedeki tüm olanaklardan çok ama çok uzaklarda kullanıyor. Kullanıcılar için - Sanırım hatırlayamazsınız.

Bir başka örnek de Peter Konov'un projesi. OOP'yi anlayamayan (istemeyen) insanlar için, iyi fırsatlarla oldukça çalışan bir çözümdür, ancak ... yine - gelir yaratma verimliliğinde bir artış gösteren tek bir örnek değil.


Bana öyle geliyor ki, bu projelerin çoğu, yazarlarının BOS'unu beslemek için daha fazla ihtiyaç duyuyor. Genel olarak, gerekli bir şey. Ancak aynı anda herhangi bir "nihai hedef" beklemeye gerek yoktur. Bu, TS Ligimden (her türden basit uzmanlardan oluşan bir dizi) izleme, kâr, Kase... beklemek gibi bir şey ama bu sadece farklı TS ilkelerinin farklı semboller üzerinde nasıl çalıştığının bir göstergesi.

 
Georgiy Merts :

Ve bu, nasıl göründüğüm önemli değil, tüm grafik kitaplıkları için ortak bir sorundur.

Forumda önerilen tüm projeler iki sorundan birini çözmelidir: ya kullanıcının gelirini artırın ya da aynı geliri elde etme verimliliğini artırın.

Projenin en az bir yazarının bu görevlerden birinin çözümünü gösteren örnekler gösterme zahmetine girdiğini hatırlamıyorum.

Genel olarak, bu programcılar forumunun bir bölümüdür ..... Burada finansal anlam aramamalısınız))) Ben kendim bu sorunları bu forumdan ayrı olarak çözmeyi tercih ediyorum.

Nikolay Semko :
Kütüphanenin nihai hedefi net değil.
Diğer kitaplıkların hangi eksikliklerini çözmeli veya geliştirmeli? Yoksa temelde yeni bir araç mı olmalı? GUI odaklı mı yoksa kullanıcı grafiği odaklı mı olmalı?
Örneğin, iCanvas kitaplığım, özel grafiklerin kullanılabilirliğini iyileştirmek, kodlama yaparken daha kısa ve daha sezgisel kod, eşzamansız işlevlerin kullanımından kaçınarak çalışma hızını artırmak, fiyata bağlama amacıyla CCanvas kitaplığının mantıksal bir uzantısıydı. -zaman koordinat sistemi ve sadece XY ekran koordinatları değil.

Kitaplığınızla başladım, teşekkür ettim, sonra biraz taradım, sonra bir tane daha, sonra bir tane daha))) sonunda yeniden yazılan çizgi işlevleri dahil her şeyi değiştirdim, ayrıca geniş çizgi işlevi tuval kaynağından, sahte işlevleri kaldırdım , olaya bir taslak koyun. W yapısından henüz tamamen çıkmadı, ancak orada da çok az şey kaldı. Sırasıyla üçüncü taraf öğeler arasında ikili arama ile soldan ve sağdan çubuğun hesaplanması eklendi, ikili aramanın kendisine daha büyük veya daha küçük bir değer seçme yeteneği ile iki yönlü eklendi. Ayrıca herhangi bir tür diziden oluşturma yeteneğini de ekledim (zaman serisi / normal) Ve tasarımın değiştirilmesi gerektiği sonucuna vardım)))))

 

Tam bir dairem olan bir şey

Hiyerarşi ile her şey açıktır.

yine kontrol ile. Yine de, ayrı ayrı çıkarmak istediğim bazı koordinatlar olduğu ortaya çıktı. Çünkü etkileşimlerin ana kısmı onlara dayanır - ve bir daire içinde. Sanırım kontrol koordinatlardan gidecek, böylece daha doğru olacak ve sistemi büyük ölçüde basitleştirecek. Tabii ki, argümanlarımda yanılabilirim - ama şu ana kadar bu naif bir karar gibi görünüyor.

Ve kontrol, stillerin temel öğesinden başka bir şey değildir - teoride koordinatlardan sonra olması gerekir.

Mantık - stilleri olmayan bir öğeye sahip olabiliriz, ancak koordinatlara sahip olamayız

 
Alexandr Andreev :

Genel olarak, bu programcılar forumunun bir bölümüdür ..... Burada finansal anlam aramamalısınız))) Ben kendim bu sorunları bu forumdan ayrı olarak çözmeyi tercih ediyorum.

Çok komik.

Yakınlarda sıcak savaşların sürdüğü, "kimse bedava çalışmayacak" konusu var - "finansal anlamda aramamalısınız" diyorsunuz ???

 
Georgiy Merts :

Çok komik.

Yakınlarda sıcak savaşların sürdüğü, "kimse bedava çalışmayacak" konusu var - "finansal anlamda aramamalısınız" diyorsunuz ???

Ortaya çıkan kütüphanenin yazarı gibi bile davranmıyorum .... Mali bileşeni hakkında ne söyleyebiliriz?

Sadece nasıl yapılması gerektiğini bilmek istedim - doğru.

Ufak bir ihtiyaçla kodu dizinizden de toplayabilirsiniz.

Her ne kadar ideal olarak, avlanma bu doğru yapının bir tür mini versiyonudur. Bu minimum kod ve maksimum kullanışlılık.

 
Nikolai Semko :
Kütüphanenin nihai hedefi net değil.
Diğer kitaplıkların hangi eksikliklerini çözmeli veya geliştirmeli? Yoksa temelde yeni bir araç mı olmalı? GUI odaklı mı yoksa kullanıcı grafiği odaklı mı olmalı?
Örneğin, iCanvas kitaplığım, özel grafiklerin kullanılabilirliğini iyileştirmek, kodlama yaparken daha kısa ve daha sezgisel kod, eşzamansız işlevlerin kullanımından kaçınarak çalışma hızını artırmak, fiyata bağlama amacıyla CCanvas kitaplığının mantıksal bir uzantısıydı. -zaman koordinat sistemi ve sadece XY ekran koordinatları değil.

Nicholas, merhaba.

Nihai hedef, halihazırda oluşturulmuş olan bu araçların eksikliklerini gidermeye çalışmaktır.

Büyük olasılıkla bunun, onu projelere bağlama kolaylığını artırmak ve grafik bileşeninin kendisini geliştirmek, grafik nesnelerinden uzaklaşmak ve tuvale geçmek için standart kitaplığın gelişiminin bir devamı olacağına inanıyorum.

Genel olarak, ne olacağını tahmin etmeyeceğiz.

 
Алексей Барбашин :

Nicholas, merhaba.

Nihai hedef, halihazırda oluşturulmuş olan bu araçların eksikliklerini gidermeye çalışmaktır.

Büyük olasılıkla bunun, onu projelere bağlama kolaylığını artırmak ve grafik bileşeninin kendisini geliştirmek, grafik nesnelerinden uzaklaşıp tuvale geçmek için standart kitaplığın gelişiminin bir devamı olacağına inanıyorum.

Genel olarak, ne olacağını tahmin etmeyeceğiz.

Kısaca mühendislik hakkında:

yeniden geliştirme yoluyla bazı "A"ları iyileştirme dürtüsü varsa, kritik eksikliklerini belirtmek gerekir. Bunları listeleyin ve "A"nın evrimsel gelişim sürecinde bunun neden kaçınılmaz olduğunu açıklayın.

öte yandan, kimse yasaklamıyor. Kod yazmayı, yazmayı seviyorum ... "A" yı yeniden yazacaksın, ama kendi yönteminle, ama yeni olacak

 
Alexandr Andreev :

Tam bir dairem olan bir şey

Hiyerarşi ile her şey açıktır.

yine kontrol ile. Yine de, ayrı ayrı çıkarmak istediğim bazı koordinatlar olduğu ortaya çıktı. Çünkü etkileşimlerin ana kısmı onlara dayanır - ve bir daire içinde. Sanırım kontrol koordinatlardan gidecek, böylece daha doğru olacak ve sistemi büyük ölçüde basitleştirecek. Tabii ki, argümanlarımda yanılabilirim - ama şu ana kadar bu naif bir karar gibi görünüyor.

Ve kontrol, stillerin temel öğesinden başka bir şey değildir - teoride koordinatlardan sonra olması gerekir.

Mantık - stilleri olmayan bir öğeye sahip olabiliriz, ancak koordinatlara sahip olamayız

Bununla tartışmaya gerek yok, öyle)))

Stiller, temalar - başlangıçta böyle bir ekleme öngörüldüğü takdirde, tüm bunlar daha sonra vidalanabilir. Aslında tüm bunlar temel kontrolde yer almalı ve dolayısıyla bu sınıfta da işlevsellik artacaktır.

Koordinatlarla ilgili olarak: burada iki tür koordinat görüyorum - grafiğe göre hesaplanan mutlak ve ebeveyne göre hesaplanan yerel.

Örneğin bir form yapılırsa, tablodaki yerleşimi mutlak koordinatlar üzerinden işlenir ve formun üzerine bir düğme yerleştirilirse, konumu, yerleştirildiği kapsayıcıya göre belirtilmelidir, yani , forma göre.

Fare hareketi olayları geldiğinde, işleyicideki grafiğe göre imleç noktasının mutlak koordinatlarını alırız. İmlecin bir forma mı yoksa herhangi bir öğeye mi çarptığını kontrol ederken, konumunu dikkate alarak imlecin mutlak koordinatlarını öğenin mevcut konumuyla karşılaştırmak gerekir. Yani, form için sadece mevcut koordinatları ve boyutu ile bir karşılaştırma olacak ve düğme için düğmenin koordinat sistemindeki mutlak konumunun hesaplanması olacaktır. Yani, karşılaştırma için X koordinatı şu şekilde hesaplanacaktır: X = (Parent==null)?X():(X()+Parent.X()), burada X(), Öğenin X konumu. Ancak, bir ebeveynin varlığının kontrolü bu işlevin kendisinde gerçekleştirilebilir. Sonuç olarak, öğenin bir ebeveyni varsa, o zaman koordinat, ebeveynin koordinatıyla ebeveyndeki kendi koordinatının eklenmesi olarak döndürülür. Aslında, yuvalanmış öğelerin sayısı isteğe bağlı olabilir ve bunların her biri, bulunduğu öğeye göre konumlandırılır ve grafiğe göre değil, böylece mutlak koordinat özyinelemeli olarak hesaplanabilir.